User community generated analytics and marketplace data for modular systems

ABSTRACT

Embodiments are directed towards providing analytics and marketplace data to members of a user community. In some embodiments, the analytics and marketplace data are generated based on machine data provided by the members. The analytics and marketplace data may enable automatically identifying, configuring, monitoring, controlling, managing, and/or maintaining a machine or a collection/system of machine components. The analytics may include, but are not limited to analytics related to machine component reliability, machine maintenance conditions, machine prohibited conditions, machine usages, machine alert conditions, and the like. The marketplace data may include information relating to the maintenance of the machine, replacement components or alternative components for the machine, and the like for various machines. Marketplace data may include an aggregation of electronic (e)-commerce data. The marketplace data may be provided is based on data aggregated from various sources, including vendors, suppliers, buyers, sellers, online auctioneers, or other members of the user community.

PRIORITY CLAIM

This Utility patent application is a Continuation of U.S. patentapplication Ser. No. 14/919,393 filed on Oct. 21, 2015, now U.S. Pat.No. 9,589,287 issued on Mar. 7, 2017, which is a Continuation-in-Part ofU.S. patent application Ser. No. 14/754,431, filed on Jun. 29, 2015, nowU.S. Pat. No. 9,588,504 issued on Mar. 7, 2017, entitled MODULAR CONTROLSYSTEM, the benefit of which is claimed under 35 U.S.C. §120, and thecontents of which are further incorporated in entirety by reference.

TECHNICAL FIELD

The present invention relates generally to managing systems formachines, and more particular, but not exclusive, to providing usercommunity generate analytics and marketplace data for modular machines.

BACKGROUND

Typically, commercial and industrial machinery have many differentcomponents and subsystems. These machines can include variousmechanical, fluid, and/or electrical systems. If one system, subsystem,or component fails, a machine may be idle for some time while thefailure is diagnosed and replacement components are ordered. The longera machine sits idle, the more money that is lost to the machines ownerand/or operator. So, identifying, configuring, monitoring, andcontrolling various aspects and characteristics of the machinery inreal-time could help in diagnosing and resolving problems before theyoccur and providing helpful solutions when they do happen. Due to thecomplexity of these machines, however, the amount data obtained bymonitoring a single machine may be overwhelming and its lack of contextmay be uninformative.

Moreover, because of the complexity of these machines, many differentskill sets may be required to diagnose a component failure, determinethe necessary repairs and/or replacement components, and perform therepair and/or install the replacement components. Sometimes a componentmay fail due to a malfunction or failure of another component, which maybe difficult to diagnose. Because of machine complexity and thedifficulty in diagnosing component failures, these machines may sit idlewhile repairs are performed, resulting in lost income. Thus, it is withrespect to these considerations and others that the invention has beenmade.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system diagram of an environment in which embodiments of theinvention may be implemented;

FIG. 2 shows an embodiment of a client computer that may be included ina system such as that shown in FIG. 1;

FIG. 3 illustrates an embodiment of a server computer that may beincluded in a system such as that shown in FIG. 1;

FIG. 4 illustrates an embodiment of a collection computer that may beincluded in a system such as that shown in FIG. 1;

FIG. 5 illustrates an embodiment of a system diagram of collectioncomputers in communication with a plurality component collections, viaID Tags and sensors, as well as a server computer;

FIG. 6 illustrates an embodiment of a system diagram of a collectioncomputer in communication with a plurality of component collections, viaID Tags and sensors associated with individual components withincomponent collections, a component multiplexor, and a server computer;

FIG. 7 illustrates an embodiment of a system diagram, where the systemis enabled to automatically identify, configure, monitor, control, andmaintain a machine, as well as provide user reports and alert conditionsregarding the current use, condition, maintenance and other aspects ofthe machine;

FIG. 8 illustrates a logical flow diagram generally showing oneembodiment of a process for identifying, configuring, monitoring,controlling, and maintaining a machine that includes a collection ofmodular components;

FIG. 9 illustrates a logical flow diagram generally showing oneembodiment of a process for identifying and configuring a machine thatincludes a collection of modular components;

FIG. 10 illustrates a logical flow diagram generally showing oneembodiment of a process for determining an expected machine usage, wherethe machine includes a collection of modular components;

FIG. 11 illustrates a logical flow diagram generally showing oneembodiment of a process for monitoring and managing machine usage,wherein the machine that includes a collection of modular components;

FIG. 12 illustrates a logical flow diagram generally showing anotherembodiment of a process for monitoring and managing the usage of amachine that includes a collection of modular components;

FIG. 13 illustrates a logical flow diagram generally showing oneembodiment of a process for monitoring managing the maintenance of amachine that includes a collection of modular components;

FIG. 14 illustrates a logical flow diagram generally showing oneembodiment of a process for determining maintenance conditions for amachine that includes a collection of modular components;

FIG. 15 illustrates a logical flow diagram generally showing oneembodiment of a process for providing marketplace data regarding themaintenance of a machine that includes a collection of modularcomponents to a user;

FIG. 16 illustrates a logical flow diagram generally showing oneembodiment of a process for providing user community generated analyticsand marketplace data for modular systems that are consistent with thevarious embodiments described herein;

FIG. 17A illustrates a logical flow diagram generally showing oneembodiment of a process for providing user community generated analyticsfor modular systems that are consistent with the various embodimentsdescribed herein;

FIG. 17B illustrates a logical flow diagram generally showing oneembodiment of a process for determining user community generatedanalytics for modular systems that are consistent with the variousembodiments described herein;

FIG. 18 illustrates a logical flow diagram generally showing oneembodiment of a process for providing user community generatedmarketplace data for modular systems that are consistent with thevarious embodiments described herein; and

FIG. 19 illustrates an embodiment of a user interface for providing amachine user analytics and marketplace data for modular systems that isconsistent with the various embodiments described herein.

DETAILED DESCRIPTION OF THE INVENTION

Various embodiments are described more fully hereinafter with referenceto the accompanying drawings, which form a part hereof, and which show,by way of illustration, specific embodiments by which the invention maybe practiced. The embodiments may, however, be embodied in manydifferent forms and should not be construed as limited to theembodiments set forth herein; rather, these embodiments are provided sothat this disclosure will be thorough and complete, and will fullyconvey the scope of the embodiments to those skilled in the art. Amongother things, the various embodiments may be methods, systems, media, ordevices. Accordingly, the various embodiments may be entirely hardwareembodiments, entirely software embodiments, or embodiments combiningsoftware and hardware aspects. The following detailed descriptionshould, therefore, not be limiting.

Throughout the specification and claims, the following terms take themeanings explicitly associated herein, unless the context clearlydictates otherwise. The term “herein” refers to the specification,claims, and drawings associated with the current application. The phrase“in one embodiment” as used herein does not necessarily refer to thesame embodiment, though it may. Furthermore, the phrase “in anotherembodiment” as used herein does not necessarily refer to a differentembodiment, although it may. Thus, as described below, variousembodiments of the invention may be readily combined, without departingfrom the scope or spirit of the invention.

In addition, as used herein, the term “or” is an inclusive “or”operator, and is equivalent to the term “and/or,” unless the contextclearly dictates otherwise. The term “based on” is not exclusive andallows for being based on additional factors not described, unless thecontext clearly dictates otherwise. In addition, throughout thespecification, the meaning of “a,” “an,” and “the” include pluralreferences. The meaning of “in” includes “in” and “on.”

As used herein, the terms “machine” and “equipment” may refer to acollection, ensemble, system, or sub-system of components. Thecomponents may be modular components. A component may be a machine part.At least a portion of the components enable and/or provide variousfunctions associated with the machine. Furthermore, the terms “machine,”and “equipment” may refer to mechanical devices that can be used at ajob site to perform actions. In at least one of various embodiments, themachine/equipment may be field-deployable or stationary. Examples ofmachines or equipment includes, but are not limited to industrial orconstruction equipment or vehicles or various components thereof.

Machines/equipment may include virtually any system or subsystem thatincludes mechanical, electrical, fluid power systems, or the like. Assuch, machines may be systems or sub-systems. Examples further includeengines, motors, pumps, pistons, valves, winches, gearboxes, powerunits, manifolds, filters, cylinders, actuators, accumulators,lubrication systems/components, control devices such as joysticks, orother mechanical/hydraulic/pneumatic devices that have characteristicsthat can be monitored by one or more sensors. As discussed furtherbelow, machines or equipment may be remotely configured, monitored,controlled, and/or at least partially maintained by one or morecollection computers in communication, via a network, with the machine.

As used herein, the term “collection computer” may refer to a networkcomputer device that can identify, configure, monitor, control, andmanage the maintenance of one or more collections of components, such asa machine. The machine components may include fs and sensors thatprovide machine data to the collection computer over a network. Thecollection computer may automatically identify each component via the IDTags, as well as collect sensor data from the sensors.

The data may be transmitted to another network computer. In someembodiments, a collection computer may be referred to as a collectionnode. In various embodiments, a collection computer may store at leastsome of the collected data. In other embodiments, the collectioncomputer may transmit at least some of the collected data to a remoteserver computer. In various embodiments, a user may be enabled tocustomize the collection computer by selecting which sensors to collect,store, and/or transmit data. Because a collection computer at leastpartially enables the remote control of a machine, a collection computermay be a controller computer. Furthermore, because a collection computerat least partially enables the management of a machine, a collectioncomputer may be a manager computer. In various embodiments, a collectioncomputer is a collection server computer.

As used herein, the terms “Identification Tag,” “ID Tag,” and “Tag” mayrefer to a readable device that includes identifying information or dataregarding a component. The identifying information may be uniquelyidentifying information, such that at least one of a component type,version, manufacturing traceability, component specifications, and thelike may be determined from reading or interrogating the ID Tag. Inaddition to identifying a type of component, information stored in theID Tag may uniquely identify the specific instance of the component. Forinstance, a unique serial number may be stored in each ID Tag thatuniquely identifies the component. Thus, both component type andspecific instances of components may be tracked via the identifyinginformation stored in the ID Tag.

ID Tags include non-volatile memory to store information pertaining tothe corresponding part. Various, but non-limiting, examples ofnon-volatile memory include read-only memory, FLASH memory (NAND orNOR), ferroelectric (Fe) random-access memory (RAM), magnetic RAM,phase-change memory (PCM or PCRAM), erasable programmable read onlymemory (ROM) (EPROM), electrically erasable programmable read onlymemory (EEPROM), and the like. Embodiments of PCM include chalcogenidememory and the like. In at least one embodiment, ID Tags include anintegrated circuit (IC) that includes onboard FLASH memory that storesthe pertinent information regarding the corresponding component.

In preferred embodiments, an ID Tag is a radio-frequency ID (RFID) Tag.When read, an RFID TAG may wirelessly provide, via electromagneticfields, the information embedded or encoded within the Tag. A Tag mayelectronically store the information. A Tag may be powered viaelectromagnetic induction that is induced by an interrogating or readingdevice. In other embodiments, the Tag may be powered via an internalpower source, such as a battery.

An ID Tag may be included in one or more components included in amachine. For instance, at least one ID Tag may be mounted directly on,on integrated with, or otherwise connected to at least one componentincluded in a collection of components, i.e. a machine. Informationregarding the associated or corresponding component may be determined bywirelessly reading and/or interrogating the ID Tag. In preferredembodiments, at least a portion of the ID Tags included in a collectionof components are in communication with one or more manger computers. Acollection computer may automatically determine information regardingthe collection of components based on the information provided by theone or more ID Tags. In preferred embodiments, one or more collectioncomputers may enable the automatic identification of at least a machinetype associated with the machine based on the information stored in themachine component ID Tags. The collection computer may further enablethe automatic configuration of the machine based on at least theinformation provided by the one or more ID Tags.

As used herein, the term “sensor” may refer to a device that measures atleast one characteristic of a machine and/or equipment. Examples ofmachine/equipment characteristics may include, but are not limited to,current load, current component movement/motion (e.g., a conveyer belt),hydraulic pressure, bearings, GPS location, gearbox temperature,hydraulic temperature, engine PRMs, vehicle speed, coolant temperature,engine coolant level, engine coolant pressure, engine oil temperature,engine oil level, engine oil pressure, engine fuel consumption rate,instantaneous fuel economy, average fuel economy, total average fueleconomy, total fuel used, total engine idle hours, total engine idlefuel used, total engine hours of operation, fuel level, or the like.Examples of sensors may include, but are not limited to, pressuresensors, temperature sensors, load cells, revolutions per minutesensors, fluid level sensors, consumption or flow rate sensors, runningtime, idle time, location sensors (e.g., GPS), video cameras, stillimage cameras, motion sensors, humidity sensors, moisture sensors,vibration sensors, sound/acoustic sensors, or the like.

In some embodiments, the sensor may be mounted to, integrated with, orotherwise connected to components within the configured, monitored, andmanaged collection of components, i.e. the machine or equipment. Invarious embodiments, one or more sensors may be in communication withone or more collection computers. In some embodiments, each sensor mayinclude or be connected to a controller that can convert signalsreceived from the sensor into messages or other data formats that can berecognized and understood by the collection computer. In onenon-limiting example, sensors may be in communication or connected to acollection computer by a controller area network (CAN), a NationalMarine Electronics Association (NMEA) 2000 network, an Aircraft DataNetwork (ADN), and the like. The network sensors may be identified by acorresponding CAN, NMEA 2000 or ADN identifier (e.g., a source address,unique sensor identifier, or the like).

As used herein, the term “template” may refer to a report or graphicalrepresentation of at least ID Tag, sensor data, machine and/or componentanalytics, marketplace data, and the like. Templates may bepredetermined and/or generated, created by a user, modified by a user,customized by a user, or the like. Each template may include one or moregauges, charts, graphs, maps, or other visualizations to represent IDTag, sensor data, analytics, marketplace data, and the like, which canbe customized by a user. A template may also indicate a machine type,such as a hydraulic pump, or the like, for a machine that isautomatically identified by the parts included in the machine.Furthermore, a template may also indicate a specific instance of amachine. Such indications of specific instances of machines may includeunique serial numbers, licenses numbers, or the like. Templates may alsoinclude features to visually represent data, such as machine dataobtained via the interrogation of ID Tags and sensors. In variousembodiments, a user may be enabled to select which ID Tags and sensorsto view corresponding ID Tag and sensor data. In other embodiments, theID Tags and/or sensors may be automatically selected for a templatebased on a machine being automatically configured and/or monitored, theID Tags and sensors providing real-time data, historical data stored atthe server, or the like.

A template may be an analytics template. Analytics templates may alsoinclude features to visually represent analytics, such as but notlimited to component reliability analytics, maintenance conditionanalytics, prohibited condition analytics, alert condition analytics,and the like. In various embodiments, a user may be enabled to selectwhich analytics to be provided with from a user community, as well aswhich analytics to provide to the user community, via a customization ofan analytics template. For instance, a user may customize which machinedata to provide to generate user community machine analytics via ananalytics template. In other embodiments, the analytics to be providedwith or to provide to a user community may be automatically selected foran analytics template based on a machine being automatically configuredand/or monitored, as discussed in conjunction with the variousembodiments described herein.

A template may be a marketplace template. Marketplace templates may alsoinclude features to visually represent marketplace data, such as but notlimited to component prices, component availability, preferred vendors,reviews of vendors and components, and the like. In various embodiments,a user may be enabled to select which marketplace data to be providedwith from a user community, as well as which marketplace data to provideto the user community, via a customization of a marketplace template. Inother embodiments, the marketplace data to be provided with or toprovide to a user community may be automatically selected for amarketplace template based on a machine being automatically configuredand/or monitored, as discussed in conjunction with the variousembodiments described herein.

Briefly stated, embodiments are directed towards providing analytics andmarketplace data to members of a user community. In some embodiments, atleast a portion of the analytics and marketplace data is generated basedon machine data provided by members of the user community. The analyticsand marketplace data may enable, or at least enhance, automaticallyidentifying, configuring, monitoring, controlling, managing, and/or atleast partially maintaining a machine or a collection/system of machinecomponents. The analytics may include, but are not limited to analyticsrelated to machine component reliability, machine maintenanceconditions, machine prohibited conditions, machine usages, machine alertconditions, and the like. The marketplace data may include informationrelating to the maintenance of the machine, replacement components oralternative components for the machine, and the like for variousmachines. Marketplace data may include an aggregation of electronic(e)-commerce data. Marketplace data may be provided (automatically ormanually) may be based on data aggregated from various sources,including vendors, suppliers, buyers, sellers, online auctioneers,members of the user community, and the like. In at least someembodiments, vendors, suppliers, and the like, as well as machine usersare included in the user community.

The analytics may be provided to the user via a populated analyticstemplate. The user may customize the analytics template to customizewhich analytics are provided and a structure for the provided analytics,as well as which members of the user community contribute machine datato determine the analytics. Likewise, the marketplace data may beprovided via a populated marketplace template. The user may customizethe marketplace template to customize what marketplace data is providedand a structure for the provided marketplace data, as well as whichmembers of the user community may contribute machine data to determinethe marketplace data.

The analytics and marketplace data may be determined based on variousanalyses of machine data, at least a portion of which is provided by theuser community. Such analyses include, but are other not limited topredictive analyses pertaining to the maintenance and reliability ofmachines that include modular components, availability of replacementand/or alternative components for the machines, and the like.Furthermore, such analyses may be based on user community generatedheuristics.

A member of the user community may generate a social network, whichincludes peers of the member. Each of the peers may also be members ofthe user community. Accordingly, a social graph may be generated foreach member of the user community. The user community generatedanalytics and marketplace data provided to a member may be updated orrefined based on the peers included in the member's social network.

At least some embodiments are directed toward automatically identifying,configuring, monitoring, controlling, managing, and/or at leastpartially maintaining a machine or a collection/system of machinecomponents, at least partially based on user community generatedanalytics. One or more collection computers, in communication via anetwork with the machine components, may enable the remote and/orautomatic identification, configuration, monitoring, controlling, andmaintaining of a machine based on at least machine readable ID Tags andsensors associated with the machine components.

Various data, including previously collected data, as well as real-timedata are utilized to identify configure, manage, and maintain themachine. At least a portion of the data may be accessible via a systemdatabase. The system database includes at least machine, component,user, user community, reliability, and market related information. Usersare enabled to customize the identifying, configuring, monitoring,controlling, and maintaining aspects of the various embodiments. Theuser may also customize data collection and various predictive analysesor determinations regarding the usage, operation, and maintenance of themachine.

A collection computer is coupled to a machine (or collection/system ofcomponents) and is in communication with a remotely located servercomputer. The collection computer may automatically detect each of aplurality of ID Tags associated with one or more components of themachine. The collection computer may additionally automatically detectsensors that provide real-time data regarding at least onecharacteristic of a first machine. In some embodiments, the collectioncomputer may monitor a network such as a Controller Area Network (CAN),a National Marine Electronics Association (NMEA) 2000 network, anAircraft Data Network (ADN), and the like. These networks may providemessage identifiers that correspond to the detected ID Tags or sensorscurrently providing real-time data to the collection computer. Invarious embodiments, a user may be enabled to select a separate samplingrate of the current real-time data for at least a portion of theplurality of sensors. The collection computer collects a real-time, ornear real-time, telemetry datastream during the operation or usage ofthe machine. The telemetry datastream includes at least a portion of theID Tag data and a portion of the sensor data.

Various embodiments are enabled to determine information that enablesthe identifying, configuring, monitoring, managing, and maintaining ofthe machines. Real time information provided by the component ID Tagsand sensors is employed in various predictive analyses to determine suchinformation. Additional information from databases or libraries includedin the embodiments further informs the predictive analyses. The analysesmay be deterministic analyses or statistical analyses. Statisticalanalyses may include likelihoods, probabilities, or confidence levelsassociated with the determined information. These analyses are utilizedto increase the functionality of the embodiments, such as monitoring,controlling, and maintaining the machine.

As discussed throughout, any of the analytics and marketplace datagenerated to identify, configure, control, manage, or maintain a machinemay be based on one or more heuristics. The heuristics may be developedover time as data, such as ID Tag and sensor data, are collected andanalyzed by the modular system. In preferable embodiments, data suppliedby machine & component manufacturers, as well the user and a usercommunity are used to develop the various heuristics. Data generated orat least provided by a subset of the user community, such as peersincluded in a member's social network, may further refine suchheuristics. Thus, as the user community and a particular social networkgrows, e.g. as the number and variety of individual users within thecommunity increases, the applicability and optimization of theheuristics is increased. Refinement of the analytics marketplace datavia a social network may direct the analytics and marketplace data tothe specific member who has generated the social network.

The heuristics may be developed automatically and/or with the assistanceor input from the user or the user's social network, or peers within thesocial network. Various embodiments may employ forms of machine learningto develop, generate, and/or update the heuristics as data from themachines (ID Tag and sensor data), manufacturers (specification andreliability data), users (specific applications and userpreferences/profile data), user community (crowd sourced reviews &configurations), as well as component and machine vendors (replacementparts availability and pricing). In at least some embodiments, componentand machine vendors may be members of the user community. Accordingly,the predictive analyses and/or heuristics are adaptive and updated toreflect the accumulating knowledge of the various machines, components,uses, and applications, generated by the users, manufacturers, andsuppliers/vendors.

Each of the determinations may be based on information provided by theID Tags and the sensors. For instance, the history of the usage of themachine may be tracked via at least sensor data. The tracking or loggingof the sensor data enables the determination of the distribution of theusage conditions of the components and the machine as a whole. Forinstance, the average, as well as the extreme operational (i.e. peak)parameters, conditions, location, environmental conditions, and the likemay be tracked to inform any of the determinations, predictive analyses,and/or heuristics as discussed throughout. For instance, after apredetermined period of use, the various embodiments may determine anaverage load on the machine, as well as a peak load based on collectedsensor data. The history of any machine, or machine component, may bearchived in one or more corresponding log files.

The ID Tags enable a self-identification of the components. Theself-identification process may identify the type of the component, aswell as the specific instance of the component type. Furthermore, IDTags may include component traceability information, such as componentmanufacturers, part/lot data, manufacturing date, factory, and the like.Accordingly, each component includes complete traceability enabled byinformation stored on the corresponding ID Tag.

The system utilizes information regarding the self-identified componentsto automatically identify the machine, as a specific collection of theself-identified components. When identifying a machine, variousembodiments may identify a machine type associated with the specificcombination of the self-identified collection of components. Forinstance, a specific combination of components may be a signature thatthe machine is a hydraulic pump. The embodiments may also determine aspecific instance of the machine type, such as these identifiedcomponents signify that the machine is User_X's hydraulic pump and isidentified by Serial No. XYZ.

Additionally, because the components included in the machine arediscoverable in real-time, the component history of a particular machinemay be logged and/or archived. Thus, the specific components included inthe machine at any point in the machine's history is traceable. Acomponent archive or history may be generated for each machine. Thus itis easily determinable that on Jun. 1, 2014, Machine_A included thefollowing components: X, Y, and Z. However the on Jun. 1, 2015,Machine_A included the following components: X, Y, and W. Thus, themaintenance history may be automatically logged via theself-identification of machine components.

Once identified (machine type and/or specific instance of the machine),a machine may be automatically configured based on the machine type,previous usage of the machine, a location or environment of the machine,an intended use of the machine, the actual components included in themachine, user community generate heuristics, and the like. Variousmachine and/or component configurations may be included in databases orlibraries. Once identified, the configurations are accessed and executedby the components and/or machine. Thus, because the identification andconfiguration of the machine and its components is automatic, theself-identifying components may be “plug-n-play” components.

As mentioned above, the various embodiments may employ prior knowledgeof the machine (a previous machine use), current machine conditions(such as machine environment, current/actual usage, machine operator,and the like), and user/user community generated analytics andheuristics to automatically predict an expected usage of the machine.The expected usage of the machine may be based on weighted averages ofprevious sensor data, as well as the peak and/or extreme values of thedata. In at least one embodiment, the distribution of sensor value data,over at least a portion of the machine's history, is evaluated whendetermining a machine's previous and expected usage.

The machine may be automatically configured based on the automaticallydetermined machine type and expected/previous machine usage. In otherembodiments, the implemented configuration may be tailored to a specificapplication of the machine. Such an application may include the expectedload, such as an engine load or torque, and expected utilization, andthe like. The user may at least partially define or update the intendedor specific application of the machine. As such, the configurationsincluded in the configuration libraries may be included in configurationfiles and tailored to, directed at, or otherwise optimized to thedetermined expected use or specific application.

Furthermore, the component sensor data enables the real-time, or nearreal-time, monitoring and managing of the machine's usage. Suchreal-time monitoring informs various predictive analyses, such as theunsafe or unauthorized operating of the machine, operating the machineoutside of its intended uses or applications, or a violation of aregulation regarding the machine's legal usage.

In an exemplary embodiment, a particular operator may not be authorizedto operate a machine outside of a limited range of operating conditions,locations, environments, time/date periods, and the like. The variousembodiments may use real-time, as well as previously logged or archivedsensor data, and other accessible data, such as user-specificpermissions and regulatory rules, to predict or determine alert and/orprohibited conditions. When an alert or prohibited condition istriggered, the various embodiments are enabled to provide an alert to auser, limit or prohibit the further use of the machine, or force themachine's operator to return the usage of the machine into compliance.

Another functionality of the various embodiments includes the remoteaccess and operation of the machine. Such remote access enables theremote controlling and managing of the machine. Remote access enablesthe remote configuration, as well as remotely varying operationalparameters during machine start-up, or even in real, or near real-timeduring the operation of the machine.

One advantage of such remote access is the remote clearing of adiagnostic alert, error condition, or prohibited condition. Forinstance, certain alerts or diagnostic conditions may require theattention and/or clearance by a specific user, or class of users such ascertified technicians. Through the employment of user credentials andpermissions, the embodiments enable members of a trusted or certifiedspecific or group of users to remotely attend to the alert. In at leastone embodiment, a certified technician may remotely attend to and“clear” an alert or warning via a remote user interface. As such,various embodiments obviate the need for a certified technician totravel to the field to attend to the condition. The remote access of themachine may be logged and reviewed for compliance at a later date. Suchremote access enables the remote troubleshooting and diagnosis ofmachine issues.

Additionally, the various embodiments store, archive, and/or log atleast a portion of the ID and sensor data, as well as other data, suchas user provided data, to inform and update future predictive analyses.For instance, tracking the usage of a machine via sensor data enablesthe embodiments to determine the machine's previous usage, loads, dutycycles, and the like. Systems implemented in the various embodiments areenabled to predict expected usages based on at least previous usages.

Information, including but not limited to the ID and sensor data areutilized to generate and/or update databases that are utilized in thevarious determinations and analyses of the embodiments. The predictiveanalyses and/or heuristics may “learn” from previous data, or are atleast updatable so that an accuracy or fidelity of the analysisincreases over time. In at least some embodiments, Bayesianmethodologies are implemented on user community generate data andanalytics to update prior knowledge of the machines that are identified,configured, monitored, and maintained by the system. Machine learning,such as neural networks, Bayesian networks, and the like may be employedto generate and/or update the predictive analyses and heuristics.

The ongoing monitoring of the machine's usage may be used to generateadditional or update existing machine and component configurationsincluded in the configuration libraries. As such, over time, updatedconfigurations may be enhanced, optimized, and/or tailored to specificusers, operators, machine applications/usages, geo-locations,environments, and the like. The various embodiments may predict and/orsuggest other configurations or other specific components orcombinations of components, where the component/configurationssuggestions are tailored to a user's expected use of the machine. Theseand other determinations made by the various embodiments may be based onweighted average values of sensor data, peak values, distributions, andthe like. For instance, the configurations may be based on the averageuse of a machine or a user may select to automatically configure thecomponents for the most extreme usage, such as a peak load on themachine.

The reliability and maintenance requirements of the machine may bepredicted or at least anticipated prior to an actual event or usageprecipitates the malfunction, diminished operation, or failure of themachine's operation. Furthermore, systems or sub-systems of the variousembodiments may determine a plurality of maintenance options, such thata user may choose the most cost-effective and/or efficient option tomaintain the machine. For instance, by tracking the actual usage of thecomponents via sensor data, the embodiments may determine a predicted orapproximate date of component failure. The determination may incorporatecomponent reliability data, as well as the expected component usage topredict a failure or replacement date, well in advance of that date. Thepredictive failure analysis may incorporate user community generate orprovided data and analytics, such as manufacture reliability data, aswell as reliability data generated by the user's social network.

In addition to providing user's various information regarding themaintenance needs of a machine, the embodiments may provide the userreal-time market data regarding replacement and/or alternativecomponents. The system may utilize market data, as well as componentdata to provide various vendors, and other parties who may supply areplacement component. The system may aggregate information regardingall known sources of a replacement part, such that the user may easilychose the most efficient option. In at least one embodiment, the systemautomatically aggregates marketplace data accessible over a network. Forinstance, the system may aggregate web-accessible market data, includingdata provided by vendors, sellers, and buyers. The system mayincorporate data available via online auction, or other e-commercesites.

Furthermore, the embodiments may use component data to providesuggestions regarding alternative choices for replacement components orparts. At least a portion of the component data may be provided mymembers of the user community to generate various analytics. Any of thedata used by the system may be provided from various members of the usercommunity, including component and machine manufactures, as well as froma community of users, suppliers, vendors, and the like. Thus, at least aportion of the data may be provided by the members of the usercommunity, and the peers included in one or more social networks. Theembodiments may suggest alternative components based on the previous,expected, or actual usage of the machine. Such suggestions may beinformed by a community of users, including the peers with the user'ssocial network, that have used various combinations of components invarious usages, contexts, locations and the like. Various heuristicsdeveloped from analytics may be employed to suggest alternativecomponents, alternative uses for, and/or alternative configurations ofmachines and systems of components. Any marketplace data provided to theuser may be local to the user's environment. In some embodiments, atleast a portion of the marketplace data includes global market data.

All of the information, capabilities, determinations, predictions, andthe like of the various embodiments may be provided to the user in anintegrated environment that includes a user interface. As such, a usermay order a replacement and/or alternative part via the user interfacewhile monitoring the machine. As such, the maintenance of monitoredmachines is much more manageable and efficient.

Illustrated Operating Environment

FIG. 1 shows components of one embodiment of an environment in whichvarious embodiments of the invention may be practiced. Not all of thecomponents may be required to practice the various embodiments, andvariations in the arrangement and type of the components may be madewithout departing from the spirit or scope of the invention. As shown,system 100 of FIG. 1 may include machine control server computer (MCSC)110, user community server computer 120, component manufacturer andsupplier server computer 130, client computers 102-105, collectioncomputer(s) 112, component sensor(s) 114, component ID Tags 116, andnetwork 108.

In various embodiments, system 100 includes a machine-managing platform140. Machine-managing platform 140 may include one or more servercomputers, such as but not limited to MCSC 110, user community servercomputer 120, component manufacturer and supplier server computer 130.Furthermore, platform 140 may include one or more instances of clientdevices, including but not limited to any of client devices 102-105.Platform 140 may include one or more collection computers, such ascollection computer 112 or and other network computer. Although notshown, platform 140 may include one or more data storage devices, suchas rack or chassis-based data storage systems. Any of the databasesdiscussed herein may be at least partially stored in data storagedevices within platform 140. As shown, any of the network devices,including the data storage devices included in platform 140 areaccessible by other network devices, via network 108.

At least one embodiment of client computers 102-105 is described in moredetail below in conjunction with client computer 200 of FIG. 2. Briefly,in some embodiments, client computers 102-105 may be configured tocommunicate with collection computers 112, MCSC 110, user communityserver computer 120, component manufacturer and supplier server computer130, and/or other network computers. In various embodiments, clientcomputers 102-105 may be enabled to access, interact with, and/or viewuser interfaces and reports provided by MCSC 110, such as through a webbrowser. In at least one of various embodiments, a user of a clientcomputer may be enabled to manipulate, configure, and/or customize themachine configuration, monitoring, controlling, maintenance, andreporting services proved by MCSC 110. The user of a client computer mayalso configure a template.

In at least one of various embodiments, client computers 102-105 may beenabled to receive alerts if an alert condition is satisfied by at leastone sensor. Similarly, client computers 102-105 may be enabled tocommunicate (e.g., via a Bluetooth or other wireless technology, or viaa USB cable or other wired technology) with collection computers 112,such as to configure a collection computer in which ID Tag and sensordata may be collected by the collection computer 112, stored at thecollection computer 112, and/or transmitted to MCSC 110. In someembodiments, at least some of client computers 102-105 may operate overa wired and/or wireless network to communicate with other computingdevices, collection computers 112, or MCSC 110. Generally, clientcomputers 102-105 may include computing devices capable of communicatingover a network to send and/or receive information, perform variousonline and/or offline activities, or the like. It should be recognizedthat embodiments described herein are not constrained by the number ortype of client computers employed, and more or fewer clientcomputers—and/or types of client computers—than what is illustrated inFIG. 1 may be employed.

Devices that may operate as client computers 102-105 may include variouscomputing devices that typically connect to a network or other computingdevice using a wired and/or wireless communications medium. Clientcomputers 103-105 may be mobile devices and may include portablecomputers, and client computer 102 may include non-portable computers.Examples of client computer 102 may include, but is not limited to,desktop computers, personal computers, multiprocessor systems,microprocessor-based or programmable electronic devices, network PCs, orthe like, or integrated devices combining functionality of one or moreof the preceding devices. Examples of client computers 103-105 mayinclude, but are not limited to, laptop computers (e.g., client computer103), smart phones (e.g., client computer 104), tablet computers (e.g.,client computer 105), cellular telephones, display pagers, PersonalDigital Assistants (PDAs), handheld computers, wearable computingdevices, or the like, or integrated devices combining functionality ofone or more of the preceding devices. As such, client computers 102-105may include computers with a wide range of capabilities and features.

Client computers 102-105 may access and/or employ various computingapplications to enable users to perform various online and/or offlineactivities. Such activities may include, but are not limited to,generating documents, gathering/monitoring data, capturing/manipulatingimages, managing media, managing financial information, playing games,managing personal information, browsing the Internet, or the like. Insome embodiments, client computers 102-105 may be enabled to connect toa network through a browser, or other web-based application.

Client computers 102-105 may further be configured to provideinformation that identifies the client computer. Such identifyinginformation may include, but is not limited to, a type, capability,configuration, name, or the like, of the client computer. In at leastone embodiment, a client computer may uniquely identify itself throughany of a variety of mechanisms, such as an Internet Protocol (IP)address, phone number, Mobile Identification Number (MIN), media accesscontrol (MAC) address, electronic serial number (ESN), or other deviceidentifier.

At least one embodiment of MCSC 110 is described in more detail below inconjunction with machine control server computer 300 of FIG. 3. Briefly,in some embodiments, MCSC 110 may be operative to communicate withclient computers 102-105 to enable users of client computers 102-105 toview, access, and/or manipulate ID Tag and sensor data stored/maintainedby MCSC 110. In various embodiments, MCSC 110 may communicate with oneor more collection computers 112 to configure the collection computer112, receive sensor data and ID Tag data from the collection computer,or the like. In some embodiments, MCSC 110 may maintain one or moretemplates which can be generated, modified, and/or customized based onID Tag and/or sensor data transmitted from a collection computer 112and/or based on input by a user (e.g., a user's selection of one or moreID Tags or sensors).

In some embodiments, MCSC 110 may monitor the ID Tag and/or sensor datato determine if an alert condition is satisfied (e.g., a temperaturevalue exceeding a threshold value). If an alert condition is satisfied,then an alert may be provided to one or more users (e.g., users ofclient computers 102-105). In other embodiments, the usage of themachine may be limited based on ID Tag or sensor data. MCSC 110 mayperform predictive analysis on ID Tag data to determine a machine type.MCSC 110 may perform predictive analysis on sensor data to determinepatterns in the sensor data to predict component failures. In someembodiments, the predictive analysis may be performed based on ID Tagand sensor data from a plurality of separate machines (which may or maynot be operated by a same customer). Any of the analyses provided byMCSC 110 may incorporate geo-data to inform such predictions. Thegeo-data may be provided by GPS transceivers included in the machine, inthe components, in the collection computer 110, the MCSC 110, and of theclient devices 102-105, or the like.

Various embodiments of the user community server computer 120 andcomponent manufacturer and supplier server computer 130 may beimplemented on a server computer, including but not limited to a servercomputer similar to machine control server computer 300 of FIG. 3. Usercommunity server computer (UCSC) 120 may receive, provide, manage,integrate, and collect various user or crowd-sourced or social networkdata as discussed throughout. For instance, UCSC 110 may receive,manage, and provide the user community data of user community database728 of FIG. 7. Furthermore, UCSC 120 may generate, update, and manageany of the predictive analyses or crowd-sourced or social networkheuristics discussed herein.

Component Manufacturer and supplier server computer (CMSSC) 140 mayreceive, provide, manage, integrate, and collect data originating frommachine and component suppliers, vendors, and manufacturers, includingbut not limited to component specification and reliability data. CMSSC140 may receive, provide, manage, integrate, aggregate, and collectmarketplace or electronic commerce (e-commerce) data. As such, CMSSC 140may provide and receive data from any of the databases included insystem database 702 of FIG. 7, such as component specification database714, component reliability database 720, marketplace database 726, andthe like.

In some embodiments, collection computer 112 is a collection servercomputer. Various embodiments of collection computers are described inmore detail below in conjunction with collection server computer 400 ofFIG. 4. Briefly, in some embodiments, collection computer 112 maymonitor and/or collect sensor data from one or more sensors 114.Collection computer 112 also collects ID Tag data from one or more IDTags 116. In some embodiments, collection computer 112 may store atleast some of the ID Tag and sensor data locally on collection computer112. In other embodiments, collection computer 112 may transmit at leastsome of the ID Tag and sensor data to MCSC 110. In various embodiments,the data that is collected, stored, and/or transmitted may be configuredby a user of client computers 102-105 and/or a user of MCSC 110. In someembodiments, collection computer 112 may monitor the sensor data todetermine if an alert condition is satisfied, and may provide one ormore alerts to one or more users based on the alert condition. In otherembodiments, collection computer 112 may perform any of the predictiveanalyses, such as those based ID Tag and sensor data to predict machinetype, machine configurations, component failures, and the like, similarto that of MCSC 110.

In some embodiments, the ID Tag or sensor data collected by collectioncomputer 112 may be based on a list of ID Tags and sensors incommunication with the collection computer 112. In at least one ofvarious embodiments, this list may be determined/defined by a user. Inanother embodiment, the list of ID Tags and sensors may include aplurality of ID Tags and sensors that are automatically detected andprovide real-time data regarding at least one characteristic of amachine. The list of ID Tags and sensors that are currently providingreal-time data may be dynamically updated based on each new ID Tagand/or sensor currently providing real-time data and each existing IDTag and/or sensor currently disabled from providing real-time data. Sothe list of current components and sensors may dynamically changedepending on components and sensors being disabled or enabled tocommunicate with the collection computer 112.

Sensors 114 may include one or more sensors in communication with one ormore collection computers 112. In some embodiments, sensors 114 maycommunicate with a collection computer 112 through a CAN, ADN, NMEA2000, or other type of network connection (e.g., USB, Bluetooth, or thelike). Sensors 114 may monitor and/or measure any of a variety ofdifferent system aspects and/or characteristics (e.g., mechanical,hydraulic, or electrical) of a machine or other equipment. These sensorsmay be directly mounted and/or integrated into one or more components ofthe machine.

ID Tags 116 may include one or more ID Tags in communication with one ormore collection computers 112. ID Tags 116 may be interrogated via ascanning device, or some other specialized hardware. In someembodiments, at least the ID Tags 116 or the interrogation hardware maycommunicate with a collection computer 112 through a CAN, ADN, NMEA2000, or other type of network connection (e.g., USB, Bluetooth, or thelike). ID Tags 116 may include embedded or otherwise stored digitalinformation that uniquely identifies the associated component includedin a machine or other equipment. At least a portion of the ID Tags 116may be directly mounted and/or integrated into one or more components ofthe machine.

Network 108 may include virtually any wired and/or wireless technologyfor communicating with a remote device, such as, but not limited to, USBcable, Bluetooth, Wi-Fi, or the like. In some embodiments, network 108may be a network configured to couple network computers with othercomputing devices, including client computers 102-105, collectioncomputers 112, MCSC 110, or the like. In at least one of variousembodiments, sensors 114 may be coupled to network computers via network108, which is not illustrated in FIG. 1. In various embodiments,information communicated between devices may include various kinds ofinformation, including, but not limited to, processor-readableinstructions, remote requests, server responses, program modules,applications, raw data, control data, system information (e.g., logfiles), video data, voice data, image data, text data,structured/unstructured data, or the like. In some embodiments, thisinformation may be communicated between devices using one or moretechnologies and/or network protocols.

In some embodiments, such a network may include various wired networks,wireless networks, or any combination thereof. In various embodiments,the network may be enabled to employ various forms of communicationtechnology, topology, computer-readable media, or the like, forcommunicating information from one electronic device to another. Forexample, the network can include—in addition to the Internet—LANs, WANs,Personal Area Networks (PANs), Campus Area Networks, Metropolitan AreaNetworks (MANs), direct communication connections (such as through auniversal serial bus (USB) port), or the like, or any combinationthereof.

In various embodiments, communication links within and/or betweennetworks may include, but are not limited to, twisted wire pair, opticalfibers, open air lasers, coaxial cable, plain old telephone service(POTS), wave guides, acoustics, full or fractional dedicated digitallines (such as T1, T2, T3, or T4), E-carriers, Integrated ServicesDigital Networks (ISDNs), Digital Subscriber Lines (DSLs), wirelesslinks (including satellite links), or other links and/or carriermechanisms known to those skilled in the art. Moreover, communicationlinks may further employ any of a variety of digital signalingtechnologies, including without limit, for example, DS-0, DS-1, DS-2,DS-3, DS-4, OC-3, OC-12, OC-48, or the like. In some embodiments, arouter (or other intermediate network device) may act as a link betweenvarious networks—including those based on different architectures and/orprotocols—to enable information to be transferred from one network toanother. In other embodiments, remote computers and/or other relatedelectronic devices could be connected to a network via a modem andtemporary telephone link. In essence, the network may include anycommunication technology by which information may travel betweencomputing devices.

The network may, in some embodiments, include various wireless networks,which may be configured to couple various portable network devices,remote computers, wired networks, other wireless networks, or the like.Wireless networks may include any of a variety of sub-networks that mayfurther overlay stand-alone ad-hoc networks, or the like, to provide aninfrastructure-oriented connection for at least client computer 103-105(or other mobile devices). Such sub-networks may include mesh networks,Wireless LAN (WLAN) networks, cellular networks, or the like. In atleast one of the various embodiments, the system may include more thanone wireless network.

The network may employ a plurality of wired and/or wirelesscommunication protocols and/or technologies. Examples of variousgenerations (e.g., third (3G), fourth (4G), or fifth (5G)) ofcommunication protocols and/or technologies that may be employed by thenetwork may include, but are not limited to, Global System for Mobilecommunication (GSM), General Packet Radio Services (GPRS), Enhanced DataGSM Environment (EDGE), Code Division Multiple Access (CDMA), WidebandCode Division Multiple Access (W-CDMA), Code Division Multiple Access2000 (CDMA2000), High Speed Downlink Packet Access (HSDPA), Long TermEvolution (LTE), Universal Mobile Telecommunications System (UMTS),Evolution-Data Optimized (Ev-DO), Worldwide Interoperability forMicrowave Access (WiMax), time division multiple access (TDMA),Orthogonal frequency-division multiplexing (OFDM), ultra wide band(UWB), Wireless Application Protocol (WAP), user datagram protocol(UDP), transmission control protocol/Internet protocol (TCP/IP), anyportion of the Open Systems Interconnection (OSI) model protocols,session initiated protocol/real-time transport protocol (SIP/RTP), shortmessage service (SMS), multimedia messaging service (MMS), or any of avariety of other communication protocols and/or technologies. Inessence, the network may include communication technologies by whichinformation may travel between client computers 102-105, MCSC 110, othercomputing devices not illustrated, other networks, or the like.

In various embodiments, at least a portion of the network may bearranged as an autonomous system of nodes, links, paths, terminals,gateways, routers, switches, firewalls, load balancers, forwarders,repeaters, optical-electrical converters, or the like, which may beconnected by various communication links. These autonomous systems maybe configured to self organize based on current operating conditionsand/or rule-based policies, such that the network topology of thenetwork may be modified.

Illustrative Client Computer

FIG. 2 shows one embodiment of client 200 that may include many more orless components than those shown. Client computer 200 may represent, forexample, at least one embodiment of client computers 102-105 shown inFIG. 1. So, client computer 200 may be a mobile device (e.g., a smartphone or tablet), a stationary/desktop computer, or the like.

Client computer 200 may include processor 202, such as a centralprocessing unit (CPU), in communication with memory 204 via bus 228.Client computer 200 may also include power supply 230, network interface232, processor-readable stationary storage device 234,processor-readable removable storage device 236, input/output interface238, camera(s) 240, video interface 242, touch interface 244, projector246, display 250, keypad 252, illuminator 254, audio interface 256,global positioning systems (GPS) receiver 258, open air gestureinterface 260, temperature interface 262, haptic interface 264, pointingdevice interface 266, or the like. Client computer 200 may optionallycommunicate with a base station (not shown), or directly with anothercomputer. And in one embodiment, although not shown, an accelerometer orgyroscope may be employed within client computer 200 to measuring and/ormaintaining an orientation of client computer 200.

Additionally, in one or more embodiments (not shown in the figures), theclient device may include an embedded logic hardware device instead of aCPU. The embedded logic hardware device would directly execute it'sembedded logic to perform actions, e.g., an Application SpecificIntegrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and thelike.

Also, in one or more embodiments (not shown in the figures), the clientdevice may include a hardware microcontroller instead of a CPU. In atleast one embodiment, the microcontroller would directly execute its ownembedded logic to perform actions and access it's own internal memoryand it's own external Input and Output Interfaces (e.g., hardware pinsand/or wireless transceivers) to perform actions, such as System On aChip (SOC), and the like.

Power supply 230 may provide power to client computer 200. Arechargeable or non-rechargeable battery may be used to provide power.The power may also be provided by an external power source, such as anAC adapter or a powered docking cradle that supplements and/or rechargesthe battery.

Network interface 232 includes circuitry for coupling client computer200 to one or more networks, and is constructed for use with one or morecommunication protocols and technologies including, but not limited to,protocols and technologies that implement any portion of the OSI model,GSM, CDMA, time division multiple access (TDMA), UDP, TCP/IP, SMS, MMS,GPRS, WAP, UWB, WiMax, SIP/RTP, GPRS, EDGE, WCDMA, LTE, UMTS, OFDM,CDMA2000, EV-DO, HSDPA, or any of a variety of other wirelesscommunication protocols. Network interface 232 is sometimes known as atransceiver, transceiving device, or network interface card (NIC).

Audio interface 256 may be arranged to produce and receive audio signalssuch as the sound of a human voice. For example, audio interface 256 maybe coupled to a speaker and microphone (not shown) to enabletelecommunication with others and/or generate an audio acknowledgementfor some action. A microphone in audio interface 256 can also be usedfor input to or control of client computer 200, e.g., using voicerecognition, detecting touch based on sound, and the like.

Display 250 may be a liquid crystal display (LCD), gas plasma,electronic ink, light emitting diode (LED), Organic LED (OLED) or anyother type of light reflective or light transmissive display that can beused with a computer. Display 250 may also include a touch interface 244arranged to receive input from an object such as a stylus or a digitfrom a human hand, and may use resistive, capacitive, surface acousticwave (SAW), infrared, radar, or other technologies to sense touch and/orgestures.

Projector 246 may be a remote handheld projector or an integratedprojector that is capable of projecting an image on a remote wall or anyother reflective object such as a remote screen.

Video interface 242 may be arranged to capture video images, such as astill photo, a video segment, an infrared video, or the like. Forexample, video interface 242 may be coupled to a digital video camera, aweb-camera, or the like. Video interface 242 may comprise a lens, animage sensor, and other electronics. Image sensors may include acomplementary metal-oxide-semiconductor (CMOS) integrated circuit,charge-coupled device (CCD), or any other integrated circuit for sensinglight.

Keypad 252 may comprise any input device arranged to receive input froma user. For example, keypad 252 may include a push button numeric dial,or a keyboard. Keypad 252 may also include command buttons that areassociated with selecting and sending images.

Illuminator 254 may provide a status indication and/or provide light.Illuminator 254 may remain active for specific periods of time or inresponse to events. For example, when illuminator 254 is active, it maybacklight the buttons on keypad 252 and stay on while the mobile deviceis powered. Also, illuminator 254 may backlight these buttons in variouspatterns when particular actions are performed, such as dialing anothermobile computer. Illuminator 254 may also cause light sources positionedwithin a transparent or translucent case of the mobile device toilluminate in response to actions.

Client computer 200 may also comprise input/output interface 238 forcommunicating with external peripheral devices or other computers suchas other mobile computers and network computers. Input/output interface238 may enable client computer 200 to communicate with one or moreservers, such as MCSC 110 of FIG. 1. In some embodiments, input/outputinterface 238 may enable client computer 200 to connect and communicatewith one or more collection computers, such as collection computers 112of FIG. 1. Other peripheral devices that client computer 200 maycommunicate with may include remote speakers and/or microphones,headphones, display screen glasses, or the like. Input/output interface238 can utilize one or more technologies, such as Universal Serial Bus(USB), Infrared, Wi-Fi, WiMax, Bluetooth™, wired technologies, or thelike.

Haptic interface 264 may be arranged to provide tactile feedback to auser of a client computer. For example, the haptic interface 264 may beemployed to vibrate client computer 200 in a particular way when anotheruser of a computer is calling. Temperature interface 262 may be used toprovide a temperature measurement input and/or a temperature changingoutput to a user of client computer 200. Open air gesture interface 260may sense physical gestures of a user of client computer 200, forexample, by using single or stereo video cameras, radar, a gyroscopicsensor inside a computer held or worn by the user, or the like. Camera240 may be used to track physical eye movements of a user of clientcomputer 200.

GPS transceiver 258 can determine the physical coordinates of clientcomputer 200 on the surface of the Earth, which typically outputs alocation as latitude and longitude values. GPS transceiver 258 can alsoemploy other geo-positioning mechanisms, including, but not limited to,triangulation, assisted GPS (AGPS), Enhanced Observed Time Difference(E-OTD), Cell Identifier (CI), Service Area Identifier (SAI), EnhancedTiming Advance (ETA), Base Station Subsystem (BSS), or the like, tofurther determine the physical location of mobile device 200 on thesurface of the Earth. It is understood that under different conditions,GPS transceiver 258 can determine a physical location for mobile device200. In at least one embodiment, however, client computer 200 may,through other components, provide other information that may be employedto determine a physical location of the mobile computer, including forexample, a Media Access Control (MAC) address, IP address, and the like.In at least one embodiment, GPS transceiver 258 is employed forlocalization of the various embodiments discussed herein. For instance,the various embodiments may be localized, via GPS transceiver 258, tocustomize the linguistics, technical parameters, time zones,configuration parameters, units of measurement, monetary units, and thelike based on the location of a user of client computer 200.

Human interface components can be peripheral devices that are physicallyseparate from client computer 200, allowing for remote input and/oroutput to client computer 200. For example, information routed asdescribed here through human interface components such as display 250 orkeyboard 252 can instead be routed through network interface 232 toappropriate human interface components located remotely. Examples ofhuman interface peripheral components that may be remote include, butare not limited to, audio devices, pointing devices, keypads, displays,cameras, projectors, and the like. These peripheral components maycommunicate over a Pico Network such as Bluetooth™, Zigbee™ and thelike. One non-limiting example of a mobile computer with such peripheralhuman interface components is a wearable computer, which might include aremote pico projector along with one or more cameras that remotelycommunicate with a separately located mobile computer to sense a user'sgestures toward portions of an image projected by the pico projectoronto a reflected surface such as a wall or the user's hand.

A client computer may include a browser application that is configuredto receive and to send web pages, web-based messages, graphics, text,multimedia, and the like. The client computer's browser application mayemploy virtually any programming language, including a wirelessapplication protocol messages (WAP), and the like. In at least oneembodiment, the browser application is enabled to employ Handheld DeviceMarkup Language (HDML), Wireless Markup Language (WML), WMLScript,JavaScript, Standard Generalized Markup Language (SGML), HyperTextMarkup Language (HTML), eXtensible Markup Language (XML), HTMLS, and thelike.

In various embodiments, the browser application may be configured toenable a user to log into an account and/or user interface toaccess/view sensor data. In at least one of various embodiments, thebrowser may enable a user to view reports of sensor data that is storedby MCSC 110 of FIG. 1. In some embodiments, the browser/user interfacemay enable the user to customize a view of the report, such as which IDTag or sensor data is displayed, what types of graphics or informationmay be displayed, or the like. As described herein, the extent to whicha user can customize the reports may depend on permissions/restrictionsfor that particular user.

In various embodiments, the user interface may present the user with oneor more initial templates for viewing the ID Tag or sensor data. In someembodiments, the templates may include gauges, graphs, maps, charts, orother visualizations that can be used to visually represent sensor data.In some embodiments, the template may include a list of sensors,component types, ID Tags, and the like that are available for which theuser can view corresponding data. This corresponding data may be currentreal-time sensor data (e.g., by employing a real-time gauge) and/orhistoric data (e.g., by using a line graph). In some embodiments, theuser may be enabled to select from a component or sensor list whichcomponents or sensors to include in the template/report. In otherembodiments, the ID Tags and sensors may be initially selected based onthe machine that is being monitored, the type of sensors being used, orthe like.

Memory 204 may include RAM, ROM, and/or other types of memory. Memory204 illustrates an example of computer-readable storage media (devices)for storage of information such as computer-readable instructions, datastructures, program modules or other data. Memory 204 may store systemfirmware 208 (e.g., BIOS) for controlling low-level operation of clientcomputer 200. The memory may also store operating system 206 forcontrolling the operation of client computer 200. It will be appreciatedthat this component may include a general-purpose operating system suchas a version of UNIX, or LINUX™, or a specialized mobile computercommunication operating system such as Windows Phone™, or the Symbian®operating system. The operating system may include, or interface with aJava virtual machine module that enables control of hardware componentsand/or operating system operations via Java application programs.

Memory 204 may further include one or more data storage 210, which canbe utilized by client computer 200 to store, among other things,applications 220 and/or other data. For example, data storage 210 mayalso be employed to store information that describes variouscapabilities of client computer 200. The information may then beprovided to another device or computer based on any of a variety ofevents, including being sent as part of a header during a communication,sent upon request, or the like. Data storage 210 may also be employed tostore social networking information including address books, buddylists, aliases, user profile information, or the like. Data storage 210may further include program code, data, algorithms, and the like, foruse by a processor, such as processor 202 to execute and performactions. In one embodiment, at least some of data storage 210 might alsobe stored on another component of client computer 200, including, butnot limited to, non-transitory processor-readable removable storagedevice 236, processor-readable stationary storage device 234, or evenexternal to the mobile device.

Applications 220 may include computer executable instructions which,when executed by client computer 200, transmit, receive, and/orotherwise process instructions and data. Examples of applicationprograms include, but are not limited to, calendars, search programs,email client applications, IM applications, SMS applications, Voice OverInternet Protocol (VOIP) applications, contact managers, task managers,transcoders, database programs, word processing programs, securityapplications, spreadsheet programs, games, search programs, and soforth.

So, in some embodiments, client computer 200 may be enabled to employvarious embodiments, combinations of embodiments, processes, or parts ofprocesses, as described herein.

Illustrative Server Computer

FIG. 3 shows one embodiment of a machine control server computer (MCSC)300, according to one embodiment of the invention. MCSC 300 may includemany more or less components than those shown. The components shown,however, are sufficient to disclose an illustrative embodiment forpracticing the invention. MCSC 300 may represent, for example MCSC 110of FIG. 1. Other network computer devices included in platform 140 ofFIG. 1, including but not limited to UCSC 120 and CMSSC 130, may beimplemented on a server computer similar to MCSC 300. MCSC 300 may be aserver computer, a server device, or simply a server.

MCSC 300 may include processor 302, such as a CPU, processor readablestorage media 328, network interface unit 330, an input/output interface332, hard disk drive 334, video display adapter 336, and memory 304, allin communication with each other via bus 338. In some embodiments,processor 302 may include one or more central processing units.

Additionally, in one or more embodiments (not shown in the figures), thecomputing device may include an embedded logic hardware device insteadof a CPU. The embedded logic hardware device would directly execute it'sembedded logic to perform actions, e.g., an Application SpecificIntegrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and thelike.

Also, in one or more embodiments (not shown in the figures), thecomputing device may include a hardware microcontroller instead of aCPU. In at least one embodiment, the microcontroller would directlyexecute its own embedded logic to perform actions and access it's owninternal memory and it's own external Input and Output Interfaces (e.g.,hardware pins and/or wireless transceivers) to perform actions, such asSystem On a Chip (SOC), and the like.

As illustrated in FIG. 3, MCSC 300 also can communicate with theInternet, or some other communications network, via network interfaceunit 330, which is constructed for use with various communicationprotocols including the TCP/IP protocol. Network interface unit 330 issometimes known as a transceiver, transceiving device, or networkinterface card (NIC).

MCSC 300 also comprises input/output interface 332 for communicatingwith external devices, such as a keyboard or other input or outputdevices not shown in FIG. 3. Input/output interface 332 can utilize oneor more communication technologies, such as USB, infrared, Bluetooth™,or the like.

GPS transceiver 358 can determine the physical coordinates of MCSC 300on the surface of the Earth, which typically outputs a location aslatitude and longitude values. GPS transceiver 358 can also employ othergeo-positioning mechanisms, including, but not limited to,triangulation, assisted GPS (AGPS), Enhanced Observed Time Difference(E-OTD), Cell Identifier (CI), Service Area Identifier (SAI), EnhancedTiming Advance (ETA), Base Station Subsystem (BSS), or the like, tofurther determine the physical location of MCSC 300 on the surface ofthe Earth. It is understood that under different conditions, GPStransceiver 358 can determine a physical location for server computer200. In at least one embodiment, however, MCSC 300 may, through othercomponents, provide other information that may be employed to determinea physical location of the mobile computer, including for example, aMedia Access Control (MAC) address, IP address, and the like. In atleast one embodiment, GPS transceiver 358 is employed for localizationof the various embodiments discussed herein. For instance, the variousembodiments may be localized, via GPS transceiver 358, to customize thelinguistics, technical parameters, time zones, configuration parameters,units of measurement, monetary units, and the like based on the locationof MCSC 300.

Memory 304 generally includes RAM, ROM and one or more permanent massstorage devices, such as hard disk drive 334, tape drive, optical drive,and/or floppy disk drive. Memory 304 stores operating system 308 forcontrolling the operation of MCSC 300. Any general-purpose operatingsystem may be employed. System firmware 306 is also provided forcontrolling the low-level operation of MCSC 300 (e.g., BIOS).

Although illustrated separately, memory 304 may include processorreadable storage media 328. Processor readable storage media 328 may bereferred to and/or include computer readable media, computer readablestorage media, and/or processor readable storage device. Processorreadable storage media 328 may include volatile, nonvolatile, removable,and non-removable media implemented in any method or technology forstorage of information, such as computer readable instructions, datastructures, program modules, or other data. Examples of processorreadable storage media include RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other media which canbe used to store the desired information and which can be accessed by acomputing device.

Memory 304 further includes one or more data storage 310, which can beutilized by MCSC 300 to store, among other things, applications 318and/or other data. For example, data storage 310 may also be employed tostore information that describes various capabilities of MCSC 300. Theinformation may then be provided to another device based on any of avariety of events, including being sent as part of a header during acommunication, sent upon request, or the like.

Data storage 310 may also include a database, text, spreadsheet, folder,file, or the like, that may be configured to maintain and store useraccount identifiers, user profiles, email addresses, IM addresses,and/or other network addresses; or the like. Data storage 310 mayfurther include program code, data, algorithms, and the like, for use bya processor, such as processor 302 to execute and perform actions. Inone embodiment, at least some of data store 310 might also be stored onanother component of MCSC 300, including, but not limited toprocessor-readable storage media 328, hard disk drive 334, or the like.

Data storage 310 may include sensor data 312, user permissions 314,templates 316, ID Tag data 342, databases 344, and/or alert conditions317. In some embodiments, this information (sensor data 312, ID Tag data342, databases 344, user permissions 314, templates 316, and alertconditions 317) may be stored on a same server computer or on aplurality of separate server computers.

Sensor data 312 may include one or more databases for sensor data thathas been collected from a collection computer (e.g., collectioncomputers 112) to MCSC 300. In various embodiments, a separate databasemay be maintained for each separate collection computer. In someembodiments, sensor data 312 may be transmitted from a collectioncomputer to the server computer via a wired or wireless connection. Inother embodiments, sensor data 312 may be provided to MCSC 300 via aclient computer, such as client computer 200. For example, a collectioncomputer may not have a wireless connection (e.g., if it is out of rangeof a cellular network tower). A user may take a client computer to thesite of the collection computer and upload the sensor data from thecollection computer to the client computer (e.g., using a USBconnection, accessing an SD card employed by the collection computer, orthe like). The user can then upload the sensor data from the clientcomputer to the server computer.

ID Tag data 314 may include one or more databases for ID Tag data thathas been collected from a collection computer (e.g., collectioncomputers 112) to MCSC 300. In various embodiments, a separate databasemay be maintained for each separate collection computer. In someembodiments, ID Tag data 314 may be transmitted from a collectioncomputer to the server computer via a wired or wireless connection. Inother embodiments, ID Tag data 314 may be provided to MCSC 300 via aclient computer, such as client computer 200. For example, a collectioncomputer may not have a wireless connection (e.g., if it is out of rangeof a cellular network tower). A user may take a client computer to thesite of the collection computer and upload the ID Tag data from thecollection computer to the client computer (e.g., using a USBconnection, accessing an SD card employed by the collection computer, orthe like). The user can then upload the ID Tag data from the clientcomputer to the server computer.

User permissions 314 may include one or more permissions for each of oneor more users. Each permission may indicate how much customization auser is authorized to perform. For example, the permissions may indicateif and how a user can customize a collection computer, such as, forexample, if a user can select which ID Tag or sensor data to collect,which ID Tag or sensor data to store locally to a collection computer,which ID Tag or sensor data to store remotely at a server computer. Thepermissions may also indicate if and how a user can customize ID Tag orsensor data reports and/or templates. In some embodiments, a user may beauthorized to view data from only a subset of a plurality of ID Tags orsensors. In other embodiments, the user may be authorized to view thedata, but may not modify the templates for displaying ID Tag or sensordata reports. In some other embodiments, the user permissions mayindicate if a user can provide alert conditions and/or when a user canreceive alerts based on alert conditions be satisfied.

Templates 316 may include one or more templates that can be employed forgenerating a configuring, monitoring, or maintenance report thatdisplays ID Tag and sensor data to a user. In some embodiments,templates may be premade, such as by an administrator. In otherembodiments, templates may be automatically generated based on a type ofmachine and/or component being monitored by the sensors. In yet otherembodiments, the templates may be automatically generated based on theID Tags or sensors that are currently providing real-time data. Invarious embodiments, at least some of the templates may be customizableby a user. The user may be enabled to manipulate which ID Tag or sensordata (e.g., by selected a sensor from a list of available sensors havingpreviously provided data) is displayed in gauges, maps, charts, graphsor other visualization.

Alert conditions 317 may store one or more alert conditions. Each alertcondition may include one or more conditions that need to be satisfiedbefore an alert is sent to a user. Each alert condition may also includea list of one or more users to provide the alert to. Along with eachuser, a type of alert may also be stored. In this way, users may beprovided customized alerts for each alert condition. As describedherein, the conditions may be for one or more ID Tags, sensors, singleevents (e.g., spikes in values, values exceeding a threshold, or thelike), multiple events, patterns, or the like.

Databases 344 may include various databases, such as but not limited tocollection computer databases, component specification databases,machine databases, machine usage databases, component reliabilitydatabases, user databases, maintenance databases, marketplace databases,user community databases, and the like. Furthermore, at least a portionof the above discussed ID Tag and sensor databases may be included indatabases 344.

Applications 318 may include computer executable instructions, which maybe loaded into mass memory and run on operating system 308. Examples ofapplication programs may include transcoders, schedulers, calendars,database programs, word processing programs, Hypertext Transfer Protocol(HTTP) programs, customizable user interface programs, IPSecapplications, encryption programs, security programs, SMS messageservers, IM message servers, email servers, account managers, and soforth.

Applications 318 may include machine identification and configurationmanager 320. Machine identification and configuration manager 320 may beoperative to automatically identify and configure a machine based on atleast one of ID Tag data 342, sensor data 312, or one or more databasesfound in databases 344, as discussed further below.

Applications 318 may also include machine usage manager 322. Machineusage manager 322 may be operative to monitor and manage the usage of amachine based on at least one of ID Tag data 342, sensor data 312, orone or more databases found in databases 344, as discussed furtherbelow.

Applications 318 may include machine maintenance manager 324. Machinemaintenance manager 324 may be operative to automatically manage themaintenance of a machine based on at least one of ID Tag data 342,sensor data 312, or one or more databases found in databases 344, asdiscussed further below.

Any of the manager applications 320, 322, and 324 may perform actions byactively managing a managing computer, such as collection computer 112of FIG. 1. In some embodiments, manager application 320/322/324 mayprovision new databases if new collection computer logs into MCSC 300.Manager applications 320/322/324 may also be operative to manage theintake of ID Tag or sensor data, such as by adding received ID Tag orsensor data to a database that corresponds to the collection computerthat collected the ID Tag or sensor data. In some embodiments, if acollection computer begins to collect ID Tag or sensor data from apreviously unknown ID Tag or sensor, at least one of the managerapplications 320/322/324 may be enabled to assign a new column within adatabase table for the collection computer for ID Tag or sensor dataobtained by the new ID Tag or sensor.

In some embodiments, at least one of the manager applications320/322/324 may be operative to provide instructions to a collectioncomputer indicating which ID Tags and sensors the collection computershould collect data from, store data locally at the collection computer,and/or transmit data to the server computer or remote storage at theserver computer. In some embodiments, these instructions may alsoindicate how often the collection computer is to collect, store, and/ortransmit data. In various embodiments, manager applications 320/322/324may include a user interface where a user may be enabled to provide thisinformation.

At least one of the manager applications 320/322/324 may be operative toenable a user to customize reports of ID Tag data 243, sensor data 312,databases 344, and the like based on permissions 314 associated with theuser. In various embodiments, manager applications 320/322/324 mayenable a user to log into an account and access a user interface wherethey can select ID Tags, sensors, gauges, graphs, or the like, which canbe employed to generate a customized report that can be displayed to theuser. In various embodiments, application managers 320/322/324 maydetermine, generate, and/or maintain templates 316.

The manager applications 320/322/324 may be operative to performpredictive analyses bases on ID Tag data 342, sensor data 314, databases344 and the like. For instance machine maintenance user 324 may beoperative to analyze ID Tag and sensor data collected by one or morecollection computers (e.g., collection computers 112 of FIG. 1), as wellas information provided by databases, such as a component reliabilitydatabase to determine one or more patterns associated with componentfailures. In some embodiments manager applications 320/322/324 mayemploy ID Tag and sensor data from one or more machines. In variousembodiments, these machines may be from different customers/users,located in similar or different geographical regions/environments, usedfor similar or different purposes, or the like.

Manager applications 320/322/324 may be operative to determine and/orgenerate alerts based on alert conditions. For instance, if an alertcondition is satisfied, machine usage manager 322 may generate andprovide an alert to one or more users based on the alert condition. Insome embodiments, manager applications 320/322/324 may employ predictivealert conditions, which may be determined based on the patternsdetermined by predictive analyzer instantiated in one or more of themanager applications 320/322/324.

So, in some embodiments, MCSC 300 may be enabled to employ variousembodiments, combinations of embodiments, processes, or parts ofprocesses, as described herein.

Illustrative Collection Computer

FIG. 4 shows one embodiment of collection server computer 400, accordingto one embodiment of the invention. Collection server computer 400 mayinclude many more or less components than those shown. The componentsshown, however, are sufficient to disclose an illustrative embodimentfor practicing the invention. Collection server computer 400 mayrepresent, for example, one of collection computers 112 of FIG. 1. Thus,collection server computer 400 may be a collection computer.

Collection server computer 400 may include processor 402, such as a CPU,processor readable storage media 428, network interface unit 430, aninput/output interface 432, hard disk drive 434, video display adapter436, GPS transceiver 440, and memory 404, all in communication with eachother via bus 438. In some embodiments, processor 402 may include one ormore central processing units.

GPS transceiver 440 can determine the physical coordinates of collectionserver computer 400 on the surface of the Earth, which typically outputsa location as latitude and longitude values. Physical coordinates of acollection server computer 400 that includes a GPS transceiver 440 maybe referred to as geo-location data. GPS transceiver 440 can also employother geo-positioning mechanisms, including, but not limited to,triangulation, assisted GPS (AGPS), Enhanced Observed Time Difference(E-OTD), Cell Identifier (CI), Service Area Identifier (SAI), EnhancedTiming Advance (ETA), Base Station Subsystem (BSS), or the like, tofurther determine the physical location of collection server computer400 on the surface of the Earth. It is understood that under differentconditions, GPS transceiver 440 can determine a physical location forcollection server computer 200. In at least one embodiment, however,collection server computer 400 may, through other components, provideother information that may be employed to determine a physical locationof the collection server computer 400, including for example, a MediaAccess Control (MAC) address, IP address, and the like. In at least oneembodiment, GPS transceiver 440 is employed for localization of thevarious embodiments discussed herein. For instance, the variousembodiments may be localized, via GPS transceiver 440, to customize thelinguistics, technical parameters, time zones, configuration parameters,units of measurement, monetary units, and the like based on the locationof the collection server computer 400.

Additionally, in one or more embodiments (not shown in the figures), thecollection computer may include an embedded logic hardware deviceinstead of a CPU. The embedded logic hardware device would directlyexecute it's embedded logic to perform actions, e.g., an ApplicationSpecific Integrated Circuit (ASIC), Field Programmable Gate Array(FPGA), and the like.

Also, in one or more embodiments (not shown in the figures), thecollection computer may include a hardware microcontroller instead of aCPU. In at least one embodiment, the microcontroller would directlyexecute its own embedded logic to perform actions and access it's owninternal memory and it's own external Input and Output Interfaces (e.g.,hardware pins and/or wireless transceivers) to perform actions, such asSystem On a Chip (SOC), and the like.

As illustrated in FIG. 4, collection server computer 400 also cancommunicate with the Internet, cellular networks, or some othercommunications network (either wired or wireless), via network interfaceunit 430, which is constructed for use with various communicationprotocols. Network interface unit 430 is sometimes known as atransceiver, transceiving device, or network interface card (NIC). Insome embodiments, collection server computer 400 may communicate with aserver computer, such as MCSC 110 of FIG. 1; sensors, such as sensors112 of FIG. 1; and/or client computers, such as client computers 102-105of FIG. 1, via the network interface unit 420.

Collection server computer 400 also comprises input/output interface 432for communicating with external devices, such as a various sensors orother input or output devices not shown in FIG. 4. Input/outputinterface 432 can utilize one or more communication technologies, suchas USB, infrared, Bluetooth™, or the like.

Memory 404 generally includes RAM, ROM and one or more permanent massstorage devices, such as hard disk drive 434, tape drive, optical drive,and/or floppy disk drive. Memory 404 may store system firmware 406 forcontrolling the low-level operation of collection server computer 400(e.g., BIOS). In some embodiments, memory 404 may also store anoperating system for controlling the operation of collection servercomputer 400.

Although illustrated separately, memory 404 may include processorreadable storage media 428. Processor readable storage media 428 may bereferred to and/or include computer readable media, computer readablestorage media, and/or processor readable storage device. Processorreadable storage media 428 may include volatile, nonvolatile, removable,and non-removable media implemented in any method or technology forstorage of information, such as computer readable instructions, datastructures, program modules, or other data. Examples of processorreadable storage media include RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other media which canbe used to store the desired information and which can be accessed by acomputing device.

Memory 404 further includes one or more data storage 410, which can beutilized by collection server computer 400 to store, among other things,sensor data 412, processes 416, and/or other data. For example, datastorage 410 may further include program code, data, algorithms, and thelike, for use by a processor, such as processor 402 to execute andperform actions. In one embodiment, at least some of data storage 410might also be stored on another component of collection server computer400, including, but not limited to processor-readable storage media 428,hard disk drive 434, or the like.

Sensor data 412 may include data that is collected from one or moresensors. In various embodiments, sensor data 412 may store sensor datauntil it is successfully transmitted to a server, such as MCSC 110 ofFIG. 1; until it is deleted by a user (e.g., if the user transfers allthe sensor data from the collection computer to a client computer (e.g.,client computers 102-105 of FIG. 1)); or the like.

Likewise, ID Tag data 414 may include data that is collected from one ormore ID Tags. In various embodiments, ID Tag data 414 may store ID Tagdata until it is successfully transmitted to a server, such as MCSC 110of FIG. 1; until it is deleted by a user (e.g., if the user transfersall the sensor data from the collection computer to a client computer(e.g., client computers 102-105 of FIG. 1)); or the like.

Processes 416 may include computer executable instructions that canexecute on processor 402 to perform actions. In some embodiments, one ormore of processes 416 may be part of an application that may be loadedinto mass memory and run on an operating system

Processes 416 may include ID Tag and sensor data collection and storage418, GPS monitor 420, ID Tag and sensor data transmission 422, userinterface 424, and system manager 426.

ID Tag and sensor data collection and storage 418 may manage thecollection/intake of data from one or more ID Tags or sensors and maymanage the local storage/logging of the collected ID Tag and sensor dataat the collection computer. As described herein, a user may customizethe collection computer such that it may or may not collect data fromeach ID Tag and sensor that it is in communication with. In someembodiments, ID Tag and sensor data collection and storage 418 maymanage the sampling rate of one or more sensors, which may be selectedby the user or automatically determined. ID Tag and sensor datacollection and storage 418 may manage the collection of ID Tag andsensor data based on the user customizations.

GPS monitor 420 may monitor GPS transceiver 440 for changes and mayreport changes to a user. In this way a user can track the movement ofthe equipment or machine that is being monitored by thesensors/collection computer. Changes in the GPS location can be employedto help determine if someone is attempting to steal the equipment, suchas if the equipment is not to be removed from a jobsite.

ID Tag and sensor data transmission 422 may manage the transmission ofID Tag and sensor data to a server, such as MCSC 110 of FIG. 1. Asdescribed herein, a user may customize a collection computer such thatit may transmit some or all collected data to the server for remotestorage by the server. The user may also be enabled to customize howoften or when data may be transmitted to the server, which may bemanaged by Id Tag and sensor data transmission 422. If the collectioncomputer is unable to transmit sensor data to the server (e.g., if thecollection computer does not have a network connection), then ID Tag andsensor data transmission 422 may wait to begin transmission once thecollection computer is again able to transmit data (e.g., if the networkconnection is restored). In some embodiments, ID Tag and sensor datatransmission 422 manage the buffering of ID Tag or sensor data (e.g., ina queue) so that when a network connection is restored, the buffereddata may be transmitted to the server.

User interface 424 may enable the user to provide the collection,storage, and transmission customizations described herein. In someembodiments, user interface 424 may enable a user to view to collecteddata in real-time or near-real time with the collection computer.

System manager 426 may provide other functionality to the collectionserver computer 400. For example, system manager 426 may provide powermanagement to the collection computer. In some embodiments, systemmanager 426 may be enabled to put the collection computer into a powersaving mode when sensors are not being monitored, theequipment/machinery being monitored is shut off, or the like. Systemmanager 426 may be enabled to “wake up” from this power saving modebased on a variety of watchdog conditions. For example, if the GPS or anaccelerometer detects a change, then the system may wake up and transmitits location to the server.

So, in some embodiments, collection server computer 400 may be enabledto employ various embodiments, combinations of embodiments, processes,or parts of processes, as described herein. Moreover, in variousembodiments, collection server computer 400 may be enabled to employvarious embodiments described above in conjunction with MCSC 300 of FIG.3.

System Overview

FIG. 5 illustrates an embodiment of a system diagram of collectioncomputers in communication with a plurality component collections, viaID Tags and sensors, as well as a server computer. System 500 mayinclude server 502 and collection servers 504-506. Server 502 may be anembodiment of MCSC 110 of FIG. 1 or an embodiment of MCSC 300 of FIG. 3.Collection servers 504-506 may embodiments, of collection computers 112of FIG. 1 or collection server computer 400 of FIG. 4.

One or more collection servers 504-506 may be in communication withserver 502. Collection servers 504-506 may provide information regardingmachine components based of ID Tag data and sensor data to server 502.The provided information may further be based on various usercustomizations. Each collection computer may be connected to or incommunication with one or more ID Tags and sensors that are associatedwith various components. For example, collection server 504 may be incommunication with component collection 508 that includes at leastcomponent_a, component_b, and component_c. Likewise, collection server505 may be in communication with component collection 510 that includesat least component_f, component_g, and component_h. Collection server506 may be in communication with component collection 512 that includesat least component_x, component_y, and component_z. As shown in system500, each of the components includes one or more associated ID Tags andsensors. Each of component collections 508, 510, and 512 may be aseparate machine, or the component collections 508, 510, and 512 may beincluded in a single machine.

More specifically, the collection servers 504, 505, 506 may be incommunication directly with one or more of the associated ID tags and/orsensors the components within the component collections 508, 510, 512.The collection servers 504, 505, 506 may communicate with the ID Tagsand sensors through a variety of different wired or wireless networks,such as, but not limited to, a CAN. Although system 500 illustrates aplurality of ID Tags and sensors communicating with each collectionserver 504 505, and 506, embodiments are not so limited, but rather, insome embodiments, a collection computer may be in communication with aID Tag or a single sensor. Similarly, although not illustrated, some IDTags and/or sensors may be connected to or communicate with a pluralityof collection computers.

FIG. 6 illustrates an embodiment of a system diagram of a collectionserver 604 in communication with a plurality of component collections608 and 618, via ID Tags and sensors associated with individualcomponents within component collections 608 and 618, a componentmultiplexor 616, and a server 602. System 600 may be an embodiment ofsystem 500 of FIG. 5. Component multiplexor 616 may be an intermediatedevice between component collections 608/618 and collection server 604.In some embodiments, sensor multiplexor 616 may be a controller formanaging signals provided by ID Tags and sensors associated with thecomponents within component collections 608/618 and converting/packagingthe signals/data into messages that can be transmitted across a network,such as a CAN, ADN, or NMEA 2000 network, to collection server 604.

FIG. 7 illustrates an embodiment of a system diagram, where system 700is enabled to automatically identify, configure, monitor, control, andmaintain a machine, as well as provide user reports and alert conditionsregarding the current use, condition, maintenance and other aspects ofthe machine. Furthermore, system 700 may predict the usage of themachine based on the included components, geo-location/environment,previous use, and the like. System 700 may be at least partiallyimplemented combinations of the devices, networks, sensors, ID Tags, andthe like shown in systems 100, 500, and 600 of FIGS. 1, 5, and 6respectively. As shown in FIG. 7, system 700 has identified andconfigured Machine_A, and is monitoring and managing the usage andmaintenance of Machine_A.

System 700 includes a system database 702 and user interface (UI) 704.Furthermore, system 700 is enabled to interrogate, or otherwise receivecomponent identification data from component ID Tags associated with thecomponents included in the machines that system 700 identifies,configures, monitors, and manages. Likewise, system 700 is operative toreceive, collect, monitor, store, and manage sensor data from sensorsassociated with the components within the machines.

In order to identify, configure, monitor, manage, and maintain machines,system 700 performs various predictive analyses based on the ID Tag andsensor data. Furthermore, the predictive analyses of system 700 may bebased on information included in the system database 702. For instance,system 700 may identify a machine type based on a self-identification ofthe components via the component ID Tags based on known combinations ofcomponent type included in known machine types, where the mappingbetween the combination of component types and the corresponding machinetype is stored in the system database 702.

System 700 may also predict a machine configuration, an expected machineusage, unsafe operation conditions, an upcoming need to replace and/ormaintain a component (maintenance conditions), and the like based on theID Tag and sensor data, as well as data included in system database 702.System 700 may even determine replacement components options in amarketplace, as well as suggest alternative components, based onavailability (local and/or global), price, reliability, user and crowdinput, and the like, for a particular machine. In any of thesedeterminations may be based on, or otherwise include, the strategicdeployment of various predicative analyses and/or heuristics.

System 700 may employ various statistical models, machine learningnetworks, heuristics, and the like for the analyses or determinationsused to identify, configure, manage, and maintain a system. Furthermore,data stored in system database 702 may be used to train, configure,optimize, generate, and/or adapt statistical models, machine-learningnetworks, and heuristics.

System database 702 may include a plurality of separate and/orsub-databases. Such databases may include, but are not otherwise limitedto a collection computer database 712, a component specificationdatabase 714, a machine database 716, a machine and component usagedatabase 718, a component reliability database 720, a user database 722,a maintenance database 724, a marketplace database 726, a user communitydatabase 728, and the like.

When identifying, configuring, monitoring, controlling, and maintaininga machine, system 700 is enabled access each of the databases includedin the system database 702. For instance, any of a collection computer,server computer, client device, and the like may be provided read and/orwrite access to each of the databases within system database 702, via anetwork. The read and/or write access may be based on, or even limited,by user permissions of a user of any such device. Data written to thedatabase may be employed to generate and/or update the variouspredictive analyses.

In an exemplary embodiment, collection computer database 712 may includea separate database for each collection computer included in system 700.Various system information, such as configuration, logs, and the likefor each collection computer may be stored in collection computerdatabase 712. For instance, collection computer database 712 may includeentries for each of collection server_1 504, collection server_2 505,and collection server_n 506 of FIG. 5.

Component specification database 714 may include information regarding aplurality of components, some of which may be included in the one ormore machines that system 700 is operative to identify, configure,monitor, manage, and maintain. Entries in component specificationdatabase 714 may include manufacturer specifications for each componentwithin the database. For instance, component specification database 714may include the specifications and other relevant information for eachof the components shown in FIG. 5, including but not limited tocomponent_a, component_b, component_c, component_f, component_g,component_h, component_x, component_y, component_z, and the like.

Database 714 may include reference/part/component numbers, componenttype, name, brand, operating parameter ranges/tolerances, and the like.Information regarding the expected, as well as the extreme ranges ofcomponent performance and operating conditions are included in componentspecification database 714. At least a portion of componentspecification database 714 may be provided directly and/or automaticallyfrom the component manufacturer. For instance, database entries may beretrieved from a network accessible database or website maintained bythe manufacturer. System 700 may access component specification database714 to obtain information regarding any of the components that areidentified, and are being configured, monitored, managed, or maintained,in real-time.

Machine database 716 includes entries for the various machines thatsystem 700 is operative or enabled to identify, configure, monitor,manage, and maintain. In preferred embodiments, machines areidentifiable by combinations of components that are likely included inthe particular machine or machine type. Machine database 716 enablessystem 700 to automatically identify a machine included in machinedatabase 716. When a machine comes online, system 700 reads or otherwiseinterrogates ID Tags associated with the components included in themachine.

The identifying information provided by ID Tags enables system 700 toidentify both the type and specific instance of a machine. The type ofmachine may be determinable via a predictive analysis of detectedcombination of the components types within the machine. For instance,the combination of components types included in the machine may becompared to one or more known component types corresponding to machinetypes within machine database 716.

The predictive analyses may be a statistical analysis that determines aprobability, or likelihood, for one or more potential machine types ofthe identified machine. The multiple potential machine types may bepresented to the user, ranked via the determined probabilities. The usermay choose, or otherwise confirm the machine type via user interface704. In other embodiments, the machine type may be determined via adeterministic look-up table within machine database 716. The look-uptable maps correlations between specific combinations of component typesand specific machine types.

For instance, consider the collection of components 508 of FIG. 5.Collection of components 508 may be included in Machine_A. Machine_A maybe a pump. An entry for Machine_A in machine database 716 includesinformation that indicates that the combination of component_a,component_b, and component_c, within a collection of components likelysignals that the machine type of Machine_A is a hydraulic pump. Also,the specific instances of component_a, component_b, and component_cindicates the specific instance of Machine_A is User_X's hydraulic pumpidentified by Serial No. XYZ. Accordingly, by interrogating theself-identifying components within a component collection 508, system700 is operative to identify the specific instance of Machine_A, as wellas the type of machine (a hydraulic pump), via a query of machinedatabase 716.

The comparison between the identified component type (or specificinstances of components) may require an exact match to determine themachine type, i.e. each of ten known component types associated with amachine type must be identified to associate that machine type with themachine being identified. In other embodiments, the strictness for amatch is relaxed, and only a threshold number of components must beidentified, for instance eight out of ten components must be identified.In still other embodiments, the known component type list may beconsidered a vector (in this example, the dimensionality of the knownvector is 10). The actual component types identified during a poweringup of the machine is another vector. If only eight components wereidentified, the dimensionality of this vector is eight. A comparisonbetween the vectors representing the known combination of componenttypes and the identified component types may be performed. A machinetype is matched if and only the distance between vector of knowncombination component types and identified component types is less thana predetermined threshold.

The first time that system 700 identifies a specific instance of amachine, system 700 may store the combination of identified componentswithin machine database 716 to uniquely define the specific instance ofthe machine. For instance, the first time that system 700 identifies thespecific combination of component_a, component_b, and component_c,system 700 stores an entry for Machine_A in machine database 716. Insome embodiments, a user may be prompted to provide additional, and orother information regarding Machine_A, to be stored within machinedatabase 716. For instance, the user may be prompted to confirm theautomatically determined or predicted machine type associated with thecombination or collection of components. Thus, look-up tables aregenerated in machine database 716, as system 700 identifies additionalmachines. Upon next identification of the specific combination ofcomponent_a, component_b, and component_c, the need for a predictiveanalyses for the machine type is not required. The now known (and userconfirmed) machine type may be queried in machine database 716 when thespecific combination of component_a, component_b, and component_c isself-identified in the future.

Likewise, machine database 716 may include entries for Machine_B andMachine_C that correspond to component collections 510 and 512 of FIG. 5respectively. Thus, when system 700 identifies the combinationcomponent_f, component_g, and component_h, via the corresponding IDTags, system 700 queries machine database 716, for the identifiedcombination. Thus, system 700 identifies at least the type and/or thespecific instance of Machine_B and Machine_C.

Machines may be uniquely identified by the unique and/or specificcomponents identified by interrogating the ID Tags. Thus, machinedatabase 716 may further track which specific instances of machinesincludes which specific components. Thus, at any point, system 700includes the knowledge, via machine database 716, of the specificcomponents included in each of the traceable machines. When a componentis replaced or switched out for an alternative component, machinedatabase 716 is automatically updated upon the next self-identificationprocess for the machine, to update the machine's entry in database 716to include the new part. Thus, machine database 716 includes the most upto date information regarding each of the machines.

Machine and component usage database 718 includes stored informationregarding the usage of machines that system 700 is operative toidentify, configure, monitor, manage, or maintain. Machine and componentusage database 718 may include operational specifications or limits ofthe machine. Machine usage may include information about previous,expected, or nominal usage of a machine or machine type. For instance,the usage may include information about previous or expected machineloads, utilization or duty factors, geo-locations, environments,day/time of use, and the like. Environment information may includetemperature, humidity, terrain conditions, elevation, and the like.

Machine and component usage database 718 may include limiting or nominalvalues for operational parameters of each machine, as well as conditionsthat would be outside the range for the safe operation of the machine.Machine and component usage database 718 may include correlationsbetween operational parameters. As such, system 700 is operative, via apredictive analyses, to determine an expected machine usage, at leastbased on a previous machine usage, a manufacturer's machinespecification, geo-location/environmental information, and the like, anyof which may be included in machine and component usage database 718.

Machine and component usage database 718 may store at least a portion ofthe telemetry datastream provided by the component ID Tags and/orsensors over a history of machine usage. The stored and/or archivedtelemetry datastream includes a tag or other such metadata so that theprevious or historical usage of a machine and its correspondingcomponents is logged. Thus, in at least one embodiment, previous and/orhistorical sensor data from the sensors associated with the machinecomponents are stored in machine and component usage database 718.

As such, machine and component usage 718 may include a log or history ofthe data obtained via the component sensors, regarding the use of themachine, i.e. the telemetry datastream. Such a log may include the totaluse, duty cycle, number of usage cycles, and the like for at least aportion of the components in a machine that is monitored and managed bysystem 700.

These logs, archives, or histories of the actual and previous machineusage for machines that have been previously monitored, managed, andmaintained may be employed in the heuristics or analyses used tomonitor, manager, and maintain the machine in the future. As such,information included in machine and component usage database 718 may beemployed to predict an actual or estimated expiration date or lifetimefor any component included in the various machines. Machine andcomponent usage database 718 may also include expected or nominalmachine usage for specific instance or types of machines that system 700may monitor and manage in the future.

Component reliability database 720 includes information regarding thereliability of components and component types that may be included inthe machines that are configured, monitored, and managed by system 700.By combining or otherwise comparing reliability information included incomponent reliability database 720 and information regarding the actualusage or history of a component (such as that included in machine andcomponent usage database 718), system 700 may perform a reliabilityanalyses. Such a predictive analysis may determine a date associatedwith an expected failure of a machine component.

Component reliability database 720 may include reliability informationprovided by the component manufacturer. At least a portion of thereliability data within reliability database 720 may be crowd-sourceddata. For instance, a community of users that have actually used acomponent may provide reliability data to include within componentreliability database. In at least one embodiment, a third party thatconducts its own reliability testing on manufactured components mayprovide reliability data to include in component reliability database720. A comparison or statistical blending of the reliability data fromthe various sources (manufacturer, crowd, reliability testing lab, andthe like) may be used to increase the accuracy of various maintenancepredictive analyses that system 700 is operative to perform. Themaintenance predicative analyses may utilize heuristics. The heuristicsmay be developed with the active assistance of one or more users, orautomatically generated and/or updated in view of the various sources ofreliability data.

User database 722 includes information regarding users of system 700.Users may include machine operators, individual's within a communitythat provide information to the various databases, users of server orclient devices of system 700, and the like. User database 722 mayinclude user credentials and system permissions associated with eachuser. User database 722 may include user profiles, histories, and thelike. User database 722 may include a history of machine operation for amachine operator user.

For example, user database 722 may include information regarding how aparticular machine operator has operated a particular, or class ormachines in the past. System 700 is operative to employ such informationincluded in user database 722, in combination with other information, isa predictive analysis to determine an expected machine usage andmaintenance requirements, such as expected component failure dates,based on the operator of the machine.

Maintenance database 724 includes information regarding the maintenancehistory of the machines and machine components. Accordingly, whenpredicting the maintenance requirements, system 700 may accessmaintenance database 724 to query when a particular component was lastreplaced. Furthermore, maintenance database 724 may be automaticallyupdated when system detects a new or replace self-identified componentwithin the machine.

Marketplace database 726 includes marketplace data for the maintenance,replacement components, alternative components, and the like. Asdiscussed throughout, marketplace database 726 may include theaggregation of online or e-commerce data. Marketplace or e-commerce datamay be provided (automatically or manually) by various sources,including vendors, suppliers, buyer, sellers, online auctioneers, andthe like.

User community database 728 may include additional data regardingmachine and machine components usages, reliabilities, availability, andthe like. User community database 728 may include crowd-sourced data. Invarious embodiments, a system user (such as a user of a server device ora machine operator) may be a member of one or more social networks.Based on various user permissions, members of these social networks maycontribute information to the user community database. Additionallyand/or alternatively, various embodiments include a machine usernetwork. Members of the machine network are users of the machines andsystems, however they may be unknown to a current operator of themachine. Members of the machine user network may also contributeinformation to the user community database.

Information in the user community database may be employed to generateand/or update the predicative analyses, including the heuristics andstatistical models, used to determine machine type, expected machineuse, machine and component configurations, alert/prohibited conditions,machine and component reliability, maintenance conditions, componentreplacement availability, alternative components, or any other suchdeterminations.

System 700 provides user interface 704 to at least a user or operator ofa machine (Machine_A), as well as a user of a client computer, a servercomputer, or any other device. User interface 704 may be a localinterface (local to Machine_A) or a remote interface (remote fromMachine_A). At least a portion of the information presented to a user ofinterface 704 may be based on data included in the system database 702,as well as ID Tag and sensor data. The user may provide information tosystem 700, via user interface 704. In various embodiments, userinterface 1900 of FIG. 19 may provide a user with any of the userinteractions discussed in conjunction with at least user interface 704of system 700. Likewise, user interface 704 may provide a user with anyof the user interactions, such as providing machine data, analytics,marketplace data, and the like, discussed in conjunction of userinterface 1900 of FIG. 19. System 700 may store the user providedinformation within database 702. Likewise, system 700 is operative tostore any ID Tag and sensor data within database 702.

User interface 702 includes a machine and component display 732. Themachine and component display 732 displays data from component ID Tagsand/or sensors included in Machine_A. Machine and component display 732may include a plurality of gauges, a map, and/or one or more graphs tovisually display or render data from one or more ID Tags and sensors. Invarious embodiments, the user may be enabled to select which ID Tags andsensors to view display 732. In at least one of various embodiments,each gauge in the interface may represent real-time (or near real-time)data from the selected sensors. In some embodiments, the user may beenabled to drag and drop the gauges into the report for viewing, whereeach gauge corresponds to a separate sensor. Machine and componentdisplay 732 may include a map of the current location of the Machine(e.g., as provided by a sensor that includes a GPS transceiver). Machineand component display 732 may also include a graph to illustratehistorical data for each ID Tags and/or sensors that is selected.

User interface 704 may also include machine controls display 734, usageand maintenance alerts/alarms display 736, and manually identifycomponents display 738. The machine controls display 734 may enable auser to interact with machine controls visually displayed with display738 and locally or remotely control Machine_A. For instance, machinecontrols with display 738 enable a user to remotely control Machine_A,as well as update operational and/or control parameters, as well asconfiguration settings.

Furthermore, usage and maintenance alerts/alarms display 736 may displayand/or provide alerts or alarms to the user regarding the real-timeusage and/or maintenance needs of Machine_A. As described herein, theuser is enabled to customize alert conditions, which if satisfied, analert or alarm may is provided to one or more users via display 736. Insome embodiments, the condition for triggering an alert may bedetermined based on a comparison of real-time sensor data and datawithin database 702, such as component specific information (such ascomponent operating parameters) included in any of componentspecification database 714, component reliability database 720, usercommunity database 728, and the like. However, additional alertconditions may also be determined, provided, and/or otherwise defined bya user.

As discussed throughout, system 700 may automatically identify variouscomponents within Machine_A via interrogating ID Tags associated withthe components. System 700 also enables a user to manually identify atleast some components via manually identifying components display 738.In some embodiments, manually identifying components display 738provides a drop-down-menu, clickable interface, or other means for theuser to manually identify or enter components included in Machine_A thatare not automatically identifiable via component ID Tags.

User interface 704 includes component, configuration, and maintenancedisplay 740. Display 740 may display each component automatically ormanually identified in Machine_A, such as P1, P2, P3, and the like. Foreach component or part, display 740 may provide links or other access toconfiguration files, maintenance files, sensor log files, and the like.In at least one embodiment, display 740 also provides at least anexpected date or deadline regarded expected maintenance, determined in amaintenance predictive analysis. For instance, system 700 may predictthat component P1 will be required to be replaced and/or maintained byJun. 17, 2018. At least a portion of the information shown in display740 may be based on information provided by system database 702, such asmachine and component usage database 718, maintenance database 724,component reliability database 720.

User interface 704 may include a machine usage display that provides theuser information regarding the usage, users, location, and the like ofMachine_A. For instance, the automatically detected machine type andgeo-location or environment of Machine_A may be displayed by display742. Likewise, display 742 may enable the display or access ofMachine_A's usage and user history, as well as duty cycle andutilization. At least a portion of the information shown in display 742may be based on information provided by system database 702, such asmachine usage database 718, machine and component usage database 718,user database 722, machine database 716, and the like.

User interface 704 includes marketplace display 744. Marketplace display744 provides the user real-time marketplace, or e-commerce, informationregarding replacement and/or alternative components for Machine_A. Forinstance, marketplace display 744 may show multiple vendors and pricesthat offer component P3. Alternative components to P3 may also be shownby marketplace 744. At least a portion of the information shown indisplay 744 may be based on information provided by system database 702,such as marketplace database 727, component specification database 714,and user community database 728.

In some embodiments, a user may select a replacement part, viamarketplace display 744 to order a replacement and/or alternativecomponent. In at least one embodiment, system 700 is enabled toautomatically a replacement part, without user action, based on aranking of the multiple choices. The ranking may be based on price,availability, component reliability, crowd-source user review, and thelike.

Generalized Operations

The operation of certain aspects of the invention will now be describedwith respect to FIGS. 8-15. In at least one of various embodiments,processes 800, 900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700,1720, or 1800 of FIG. 8, 9, 10, 11, 12, 13, 14, 15, 16, 17A, 17B, or 18respectively, may be implemented by and/or executed on a combination ofcomputers, such as collection server computer 400 of FIG. 4; clientcomputer 200 of FIG. 2; and/or MCSC 300 of FIG. 3. Additionally, variousembodiments described herein can be implemented in a system such assystem 100 of FIG. 1.

FIG. 8 illustrates a logical flow diagram generally showing oneembodiment of a process for identifying, configuring, monitoring,controlling, and maintaining a machine that includes a collection ofmodular components. As discussed throughout, at least some of themodular components include an ID Tag. Furthermore, one or more of thecomponents includes one or more sensors. Process 800 may begin, after atstart block, at block 802, where the machine is identified and/ordetermined. Various embodiments of determining a machine are discussedin the context of FIGS. 9 and 10. However briefly, at block 802, amachine type may be determined based on interrogating or receiving datafrom a plurality of ID Tags associated with components included in themachine. Furthermore, the machine may be uniquely identified as aspecific instance of the machine type. The specifically identifiedmachine may be uniquely defined by a serial number or the like based onthe self-identified components types and/or specific instances of theself-identified components. For instance, the machine may be uniquelyidentified.

In at least one embodiment, the machine includes a dedicated ID_Tag thatincludes identification data for at least the machine type or the uniqueinstance of the machine. In such embodiments, the identification of theincluded components and/or component types may not be required. Thedetermination at block 802 may be an automatic determination. A machineuser may be prompted to confirm the determination of the machine and/orprovide additional information. In at least some embodiments, thedetermination may be based on at least components that were manuallyentered by a machine user.

Process 800 proceeds to block 804 where the machine is configured.Various embodiments of configuring a machine are discussed in thecontext of FIGS. 9 and 10. However briefly, at block 804, the machine isconfigured based on at least the machine determination/identification atblock 802. For instance, configuring the machine may be based on atleast the identified machine type or the specific instance of themachine. In some embodiments, the machine is further configured based onan expected usage of the machine, which as discussed below, may be basedon the previous usage of the specific machine, or by the history of themachine operator. The previous and/or expected usage may be based on acommunity of users of the machine, a user social network, or othersources of crowd-sourced data aggregation, for instance, one or morecrowd-generated heuristics.

Furthermore, the expected usage may be based on an environment orgeo-location of the machine, a user of the machine, user permissionsassociated with the user, and the like. The configuration of the machinemay be based on the environment (automatically determined via GPSenabled component sensors). For instance, if the environment is a desertenvironment the machine may configured on a first configuration and ifthe environment is a forest or a high altitude environment, the machinemay be configured in a second configuration. The machine may beautomatically configured or a user may provide at least a portion of theconfiguration. A user may be prompted to verify the configuration. In atleast one embodiment, a user at least partially configure the machinevia a user interface, such as user interface 704 of FIG. 7. A machineconfiguration may include configurations for one or more of thecomponents included in the machine.

At block 806, the machine usage is monitored. Various embodiments ofmonitoring machine usage are discussed in the context of FIGS. 11 and12. However briefly, at block 806, the usage of the machine is monitoredin real time by collecting and/or receiving sensor data from the varioussensors corresponding to machine components. The monitoring of themachine may be at least partially based on the configuration of themachine. For instance, the user may configure the collection anddisplaying of the various sensors displayed in user interface 704 ofFIG. 7.

Monitoring the machine may include collecting and analyzing thedatastream provided by the sensors. For instance, the sensors providereal-time telemetry of the operating conditions of the machine. Thetelemetry datastream may be analyzed to determine alarm/alertconditions. At least a portion of the telemetry, including data providedby the ID Tags and sensors may be stored in various databases, such assystem database 702 of FIG. 7. In at least one embodiment, monitoringmachine usage includes determining an actual machine usage based on thereal-time telemetry datastream.

At block 808, the machine's usage is at least partially managed and/orcontrolled. Various embodiments of managing the machine's usage arediscussed in the context of FIGS. 11 and 12. However briefly, at block808, the machine usage is managed based on at least one of the machineconfiguration, the telemetry datastream generated by at block 806 (suchas component sensor data), the system database 702, or user providedinformation. At least a portion of the machine usage management may beautomatic. Another portion of the machine usage management may bemanually performed by a user, such as a user of system 700 of FIG. 7.For instance, a user may remotely interact with, control, or otherwiseoperate the machine, via a user interface, such as user interface 704 ofFIG. 7.

Process 800 proceeds to block 810 where at least a portion of themachine's maintenance is managed. Various embodiments of managing themachine's maintenance are discussed in the context of FIGS. 13, 14, and15. However, briefly, at block 810 the machine maintenance is managedbased on at least one of the machine configuration or the monitoredmachine usage. Predictive analyses or heuristics may be employed toinform a user, in advance, of an upcoming need to maintain the machine,such as replacing a component. E-commerce marketplace data is providedto the user, and the user is presented replacement and/or maintenanceoptions. At least a portion of the market data may be crowd sourced froma social network that includes the user and/or a machine user network.Vendors and/or suppliers may contribute to the marketplace data. Theuser may order replacement components directly from the user interface.Replacement components may be automatically ordered, with or withoutintervention via the user, so that components are available in advanceto a scheduled replacement data, without user intervention or action.

Process 800 is an adaptive process, in that any of the determinationsincluded in process 800, or any sub-processes of process 800 may beupdated or adapted based on the real-time operating or usage conditionsof the machine. Such real-time information may be determined based onthe telemetry datastream generated by monitoring the machine usage, i.e.the actual machine usage. One such example of an adaptive feedback loopis enabled be decision block 812, where it is determined if the machineconfiguration should be updated. For instance, the configuration may beupdated in real-time and based on the actual machine usage. When anupdated machine configuration may be beneficial to the operation of themachine, process 800 proceeds to block 816. If the configuration is notto be updated, process 800 proceeds to decision block 814.

At block 816, the configuration is updated or adapted based on theactual machine usage. For instance, the real-time telemetry datastream(data from the sensors and ID Tags) may be used to update theconfiguration. After the configuration has been updated, process 800returns to block 806 to continue monitoring the machine usage.

At decision block 814, it is determined if the machine usage is to beterminated. For instance, if the machine is taken offline, or powereddown, the machine usage is terminated. If the machine usage is notterminated, then process 800 returns to block 806 to continue monitoringthe machine usage. Otherwise, process 800 terminates and/or return to acalling process to perform other actions.

Identifying and Configuring a Machine

FIG. 9 illustrates a logical flow diagram generally showing oneembodiment of a process for identifying and configuring a machine thatincludes a collection of modular components. Process 900 begins, after astart block, at block 902, where a machine is powered up. In at leastone embodiment, at block 902, a machine may come available online, or isotherwise enabled to communicate to a collection computer or a servercomputer over a network.

Process 900 proceeds to block 904, where components in the machine aredetermined. At least a portion of the determined components may beidentified based on one or more ID Tags included with the components. IDTags may provide component identification data to a collection computerwhen interrogated. The component identification data may be providedwirelessly. In at least one embodiments, an RFID Tag is remotelyinterrogated and transmits the component identification data to thecollection computer. The interrogation may be wireless, i.e. thecollection computer or some other device may wirelessly provide a signalto the ID Tag to transmit the component identification data. In otherembodiments, the interrogation may be received over a wired network. Forinstance, if the ID TAG includes EEPROM, a voltage on a pin may betransitioned to a read state.

The specific component, as well as a component type may be determined atblock 904. At least a portion of the components may be self-identifiedvia an interrogation of or receiving the data stored in the ID Tags. Forinstance, some of the components may be self-identified by an automaticinterrogation of one or more of the ID Tags. Accordingly, at least someof the components and/or component types of the machine may beautomatically determined upon powering on of the machine. Thus,self-identifying the components may be automatically performed during apower-up cycle of the machine.

In at least one embodiment, once a component has been identified, theinclusion of the component may be stored with the collection computer,such as collection sever computer 112 of FIG. 1, or a server computer,such as MCSC 110 of FIG. 1. Thus, once identified, in some embodiments,it may not be required to interrogate the ID Tags upon each powering upof the machine, unless the arrangement or inclusion of components hasvaried between successive power-up cycles (such as when a component hasbeen replaced).

In some embodiments, the functionality or operability of the componentis determined upon identification of the component. For instance, afteridentification, the collection computer may put the component into a“warming-up” mode or a test mode. In such embodiments, the collectioncomputer may verify that the component functions within the manufacturespecifications or at least within the limits tested in the test mode. Ifone or more components are determined to not be fully functional, analert or alarm may be provided to the user.

In some embodiments, at optional block 906, a user is enabled tomanually determine additional components included in the machine. Forinstance, some components may not include an ID Tag, or the included IDTag has malfunctioned, or is otherwise not readable upon powering up ofthe machine. In such instances, a user may manually identify suchcomponents. In at least one exemplary embodiment, a user of userinterface 704 of FIG. 7 may manually enter components that were notautomatically determined or identified during the power-up cycle. Themanually identified components display 738 of user interface 704 may beoperative to assist the user in entering these additional components. Inat least one embodiment, one or more components are suggested to theuser, via the user interface, based on additional components that arelikely included with the combination of components that wereself-identified at block 904.

At block 908, the machine type is determined based on at least thedetermined components. In various embodiments, the type of the machineis automatically determined based on the self-identified componentsdetermined at block 904. The determined machine type may be furtherbased on the manually identified components of block 906. The machinetype may be based on the specific combination of components or componenttypes determined or identified at blocks 904 and 906. In at least oneembodiment, the machine includes one or more dedicated ID Tags thatinclude the machine type corresponding to the machine.

The machine type may be determined based on information from one or moredatabases, such as the databases within system database 702 of FIG. 7,such as machine database 716. The machine entries in machine database716 may include lists or tables of components typically included in themachine types within machine database 716. Such component collectionsincluded in the machine database may be consulted to determine themachine type. A look-up table may be consulted to determine the machinetype. The look-up table may include one or more possible specificcombination of components or component types that map or correspond tothe machine type.

As noted throughout, a statistical analysis may be performed, andstatistical probabilities assigned to one or more potential machinetypes. In at least one embodiment, a heuristic may be employed todetermine the machine type. The database entries, look-up tables,statistical models, and heuristics may be updated to incorporate orintegrate newly generate user or user community data. The user may beprompted to verify the determined machine type.

In some embodiments, in addition to the machine type, the specificinstance of the machine may be uniquely determined or identified atblock 908. For instance, the specific combination of the specificcomponents determined at blocks 904 and 906 may indicate a specificmachine. A look-up table may be included in machine database 716, wherethe specific combination of the specific identified components indicatesa specific machine. A serial number or some other unique identifier maybe assigned to uniquely indicate the specific machine. The uniqueidentifier tracks the specific machine in the various databases includedin the system database 702, as well as through the various predictiveanalyses.

In at least one embodiment, one or more of the ID Tags included in themachine, such as the dedicated machine ID Tag, or any other ID Tagassociated with the components of the machine, are programmable and/orwritable from a distance, i.e. a collection computer, a server computer,or a client device may write information to store information on a IDTag. According, once the machine or the machine type has beenidentified, the identified machine type or unique serialization number(or any other type of information or data) may be stored on thededicated ID Tag. This new stored information may be automatically read,along with the component identification data upon reading of the IDTags. Accordingly, the information stored in the ID Tags may be updatedor adapted during the life cycle of the machine or the components of themachine.

At block 910, the expected machine usage is determined. Variousembodiments of determining the expected usage of the machine arediscussed in the context of FIG. 10. However briefly, once the machinehas been identified, predictive analyses or heuristics are utilized todetermine an expected usage of the machine. The expected usage may bebased on a previous machine usage, the specific machine operator, theuser's social network, network of machine users, and the like. Forinstance, the previous usage may be based on a prior use of thespecifically identified machine and/or a previous usage of anothermachine that is of an equivalent or similar machine type.

The expected usage may be based on a specific application of themachine, such as an application defined by a user. The expected usagemay be further based on the operator or user of the machine, userpermissions of the user, geo-location or environment of the user, andthe like. A predictive analysis determines the likely expected use ofthe machine based on knowledge of how the machine (and/or other machinesof similar machine type) was previously used, location, user community,and the like. Information included in system database 702 may be used inthe predictive analysis, including but not limited to machine &component usage database 718, user database 722, user community database728.

At block 912, the machine is configured. The machine may be configuredbased on at least one of the determined components/component type or theexpected machine usage. In at least one embodiment, the machine isconfigured based on the determined machine type and/or the specificinstance of the machine. In at least one embodiment, the determinedconfiguration may be based on specific components, the machine operator,user permission, machine geo-location and environment, previous machineusage, and the like. The user may be prompted to verify theconfiguration. In at least one embodiment, a portion of the componentsare individually configured based on the determined.

In at least one embodiment, the configuration is based on thegeo-location and/or environmental factors. For instance, the machine maybe configured differently if the machine is located in a desertenvironment, as opposed to a forest, coastal, or mountainousenvironment. Block 1008 of FIG. 10 discusses various embodiments fordetermining a geo-location or environment of the machine.

A configuration may include a machine configuration, as well asconfigurations for the individual components included in the machine.Configuration files (machine and/or component files) may be loaded fromvarious configuration libraries included in the system database based onthe determined configurations for each of the components. The user mayupdate the various configurations during the operation of the machine.In at least one embodiment, the system tests the functionality of thecomponents once the components are configured. In a least oneembodiment, a localization of at least a portion of any of the processesdiscussed herein is performed based on at least the geo-location data.For instance, time zone parameters, currency type, units, languageparameters, and the like are set or otherwise configured in variousportions of any of the processes discussed herein.

Process 900 is an adaptive process, and thus provides feedback loops toadapt and/or update the configuration of the machine, as the usage oroperation of the machine is varied or changes over time. Thus, afterconfiguring the machine, process 900 flows to block 914, where themachine usage is actively monitored. Various embodiments of monitoringthe machine usage are discussed in the contexts of FIGS. 11-12. Oneembodiment of monitoring the machine usage is discussed in the contextof block 806 of adaptive process 800 of FIG. 8. A real-time telemetrydatastream that includes information regarding the usage or operation ofthe machine is received in block 914. The actual machine usage may bedetermined when monitoring the machine at block 914.

At decision block 916, it is decided if the expected machine usage is tobe updated. For instance, if the expected machine usage, determined atblock 910, varies from the actual machine usage, beyond a tolerance orthreshold level, the expected machine usage may be updated. If theexpected machine usage is to be updated, process flows to block 918,otherwise process 900 flows to decision block 920.

At block 918, the expected machine usage is updated based on the actualmachine usage determined at block 914. In at least one embodiment, theexpected machine usage is updated and/or adapted to be similar to theactual machine usage, within the predetermined tolerance level. Variousadaptive heuristics may be employed to update the expected machine usagein view of the actual machine usage.

Process 900 flows to decision block 920, where it is determined if theconfiguration is to be updated, For instance, the configuration may beadapted to updated to be optimized for the actual machine usage. If theconfiguration is to be updated, process 900 flows to block 922, wherethe configuration is updated. The configuration may be updated based onat least one of the actual machine usage or the updated expected machineusage. Block 816 of FIG. 800 discusses various embodiments that includeupdating the machine configuration. Otherwise, process 900 terminatesand/or returns to a calling process to perform other actions.

FIG. 10 illustrates a logical flow diagram generally showing oneembodiment of a process 1000 for determining an expected machine usage,where the machine includes a collection of modular components.Essentially, process 1000 provides one or more predictive analyses fordetermining the expected usage of a machine. The predictive analyses isbased on various known factors about the type and specific machine,including previous use (nominal, average, peak), machine operator,environment (desert, jungle, high altitude, forest, underwater, and thelike), user permissions, regulatory schemes that govern the usage ofmachine, and other such factors that are useful to predict the expectedusage.

The previous usage may be based on previous machine monitoring, forinstance monitoring and logging the sensor data during previous usagesof the machine, via one or more telemetry datastreams. This priorknowledge may be stored in the system database. As noted throughout,process 1000 is an adaptive process, and thus the various predictions,determinations, or heuristics may be updated or adapted as newinformation regarding the machine becomes available to the embodiments.For instance, a predicative heuristic may be updated when newinformation becomes available via a telemetry datastream received duringmonitoring of the machine, a user social network, or a machine usernetwork is updated.

Process 1000 may begin, after at start block, at block 1002, where amachine type is determined based on the determined and/orself-identified components. In at least one embodiment, at block 1002,the machine type is determined in a similar manner as discussed inregards to block 908 of process 900 of FIG. 9. For instance, ID Tagsassociated with the machine components may enable theself-identification of the components/component types and themachine/machine type. As such, the machine database 716 of FIG. 7 may bequeried to determine the machine.

At optional block 1004, a machine user may be determined. The machineuser may be a machine operator. The machine operator may locally orremotely operate the machined. For instance, the machine may be at leastpartially operated via remote or local user interface 704 of FIG. 7. Auser may be determined by prompting the user for user credentials.Furthermore, a user social network and/or a machine user network may bedetermined at block 1004.

At optional block 1006, user permissions may be determined. Userpermissions may be determined via user credentials. In at least oneembodiment, user database 722 of FIG. 7 may be accessed to determine theuser, as well as user permissions. Additionally, user community database728 may be used to determine the social and machine user networks.

At optional block 1008, the geo-location of the machine is determined.In some embodiments, the geo-location or global position is determinedby employing at least a GPS transceiver. One of the sensor componentsincluded in machine may be a GPS transceiver. In other embodiments, aGPS transceiver included in a collection computer, a server computer, ora client computer may provide the geo-location. Once the geo-location isdetermined, various environmental factors are determinable by process1000. For instance, the machine's elevation may be determined. It mayalso be determined if the machine is located in a desert, coastal,mountainous, forested, or humid environment. In at least one embodiment,the configuration of the machine is based on the geo-location orenvironmental factors determined at block 1008. In at least oneembodiment, the environment is automatically determined. A user may beprompted to verify or confirm the automatically determined environmentand/or geo-location.

At optional block 1010, the previous machine usage is determined. In atleast one embodiment, the machine and component database 718 of FIG. 7is queried to determine the previous machine usage. The previous machineusage may be based on previous telemetry datastreams associated with thespecific instance of the machine and/or specific components included inthe machine. The previous machine usage may include values for thesensor data collected during previous usages of the machine. Forinstance, the previous machine usage may include nominal, weightedaverages, or peak values of the sensor data. In at least one embodiment,the previous machine usage includes statistical distributions ofprevious sensor data values. In some embodiments, the previous machineusage is based on the user's previous use. Additionally, the machine'sprevious usage may be based on a community of users of similar machinesand/or one or more social networks of the user. Accordingly, theprevious usage may be based on heuristics generated via crowd-sourceddata.

At block 1012, the expected usage of the machine is determined. Thedetermination of the expected machine usage is based on at least one ofthe determined machine type, geo-location, environment, machine user,user permissions, user community, the previous machine usage, and thelike. The determination of the expected machine usage may included apredictive analysis that incorporates information from any of thedatabases included in system database 702 of FIG. 7, as well as usersupplied information. In at least one embodiment, a suite of heuristicsis employed to integrate and blend the various sources of data todetermine the machine's expected use. As with the previous machineusage, the expected machine usage may include nominal, weightedaverages, peak values, or statistical distributions of expected sensordata.

As noted throughout, process 1000 is an adaptive process. As such, theexpected machine usage may be periodically updated to incorporate dataregarding the actual machine usage. For instance, as statisticaldistributions of actual sensor data becomes available, thesedistributions may be included or incorporated in the determined expectedmachine usage. The expected machine usage may be updated via aBayesian-like process, where the previous sensor data distributionsrepresent the prior knowledge, and the actual sensor data distributionsare utilized to update the prior knowledge. In this way, the expectedmachine usage is adapted, over time, to more accurately reflect theactual machine usage. After block 1012, process 1000 may terminateand/or return to a calling process to perform other actions.

Monitoring and Managing the Operation of a Machine

FIG. 11 illustrates a logical flow diagram generally showing oneembodiment of a process for monitoring and managing machine usage,wherein the machine that includes a collection of modular components.Process 1100 begins, after a start block, at block 1102, where one ormore alert conditions for the machine are determined. In at least oneembodiment, determining the alert conditions is based on the expectedmachine usage. The expected machine usage may be determined by a processsimilar to the various embodiments discussed in the context of at leastFIG. 10. In at least one embodiment, the alert conditions may be basedon crowd-source data, such as the user's social network or a communityof operators of similar machines and/or components. For instance, acommunity of users may have discovered various operational scenarios ormodes that have not been known or previously published. Viacrowd-sourced data, other conditions may be determined for suchconditions.

In some embodiments, determining the alert conditions is based oninformation included in the system database, such as componentspecification database 714, component reliability database 720, machinedatabase 716, user community database 728, or any other database of FIG.7.

Alert conditions may be sensor values or patterns in the sensor value.Alert conditions may be a sensor value exceeding a predeterminedthreshold, spikes in a sensor value, a rate of change in a sensor valueexceeding a predetermined threshold, or the like, which when satisfiedmay trigger an alert to be sent to one or more users.

In some embodiments, conditions may be single events, such as a singletemperature value exceeding a threshold value. In other embodiments,conditions may be repeating events, such as a temperature valueexceeding a threshold value for a given period of time. In otherembodiments, the conditions may be a pattern of events, such as atemperature value being above a first threshold value for a given time,then falling below second threshold, then increasing at a given ratebefore peaking above a third threshold value.

In various embodiments, an alert condition may correspond to a singlesensor. For example, a temperature sensor exceeding a threshold value.In other embodiments, an alert condition may be based on a combinationof a plurality of sensors. For example, a temperature sensor exceeding athreshold value and a rate of increase of revolutions per minute (RPMs)being above another threshold value. These examples of types ofconditions is for illustrative purposes and should to be considered asexhaustive or limiting.

In some embodiments, the alert conditions may be provided by a user(e.g., an administrator). In other embodiments, the alert conditions maybe based on a manufacturer's component's specification. For example,each sensor may be associated with one or more components. In someembodiments, a user may be enabled to customize which sensors areassociated with which components. In at least one of variousembodiments, a database of components and their manufacturespecifications and/or operating parameters may be maintained. Eachcomponent or line item in the database may include metadata oridentifiers of the sensors it is associated with.

In various embodiments, alert conditions may identify one or more usersthat may be provided an alert if the condition is satisfied.Additionally, alert conditions may include an identifier of the type ofalert than may be provided to each user. In this way, alert conditionsmay be customized for different conditions, different users, anddifferent alert types. Users may include, but are not limited to,mechanics, engineers, site foreman, managers (e.g., a project manager,account manager, finance manager, or the like), or the like. In variousembodiments, each of a plurality of users may have a role that mayprovide access or restrictions to one or more alert conditions and/orcollection computer customization.

Since alert conditions may be customized for each user, some users mayreceive an alert, while others do not. For example, if the oil pressurefalls below a predetermined threshold, then a text message may be sentto a mechanic. But if the lifting capacity of a bucket-arm goes below apredetermined threshold then an alert may be sent to a lead engineer andthe mechanic. Similarly, alert conditions may include escalation rules,such that if an alert condition is satisfied a predetermined number oftimes within a predetermined time period then alerts may be provided toadditional users. Continuing the example above, if the oil pressurecontinuously fall below the threshold, then an alert may be provided toa site manager as well as the mechanic. So in some embodiments, alertconditions may include a plurality of thresholds where different usersare notified depending on the threshold exceeded.

In another example, alert conditions may be employed to compare usage ofone machine to the usage of another machine. For example, assume abusiness has a fleet of garbage trucks. Each garbage truck may beequipped with a load cell or other sensor for detecting the weightand/or capacity status of the corresponding garbage truck. An alertcondition may be determined for each garbage truck such that if theweight for a garbage truck exceeds a predetermined threshold, then analert (at block 1308) may be provided to a manager. The manager may beable to use this information to tell the heavy garbage truck to stopcollecting garbage, reroute other garbage trucks to continue the heavygarbage truck's route, or the like. In various embodiments, anotheralert condition may be dependent on the weight alert condition such thatif a garbage truck is continuously over weight, then the manager canalter future routes, schedule extra maintenance on the overweightgarbage truck, or the like.

In some embodiments, alert conditions may be employed to provideadditional information to various management and/or businessentities/users. For example, alert conditions may provide alerts if amachines operating time exceeds a lease agreement operating time. Inanother example, an alert condition may indicate that a differentbilling structure may be utilized. For example, an alert condition mayindicate which operator is running the machine, since differentoperators may have different billing rates. It should be recognized thatthese examples are for illustration purposes and virtually any alertcondition relating to a machine and/or its operation may be employed.

At block 1104, the sensor data is collected. In various embodiments,real-time data may be provided from one or more sensors measuringcharacteristics of a machine, which may be collected by a collectioncomputer, such as described herein. In various embodiments, ID Tag datais additionally collected.

In various embodiments, at least a portion of data may be collected, notin real time, but after at some point after the sensors and/or themachine usage has generated the data. For instance, the data may bebuffered and communicated at regular time intervals. The data may becommunicated after the machine is powered down. In at least oneembodiments, sensors may provide data regarding the condition of themachine when not in use. The sensor and/or ID Tag data may be stored,logged, or archived in the system database.

At block 1106, the collected sensor data is monitored. The sensor datamay be monitored in real-time, or close to real-time as it is collectedin block 1104. The sensor and/or ID Tag data may be stored, logged, orarchived in the system database.

In any event, process 1100 may flow to decision block 1108, where adetermination may be made whether an alert condition is satisfied. Thisdetermination may be made based on a comparison of the collected sensordata and the alert conditions. For example, the sensor data may bemonitored to determine if a threshold value is exceeded, a rate ofchange is observed, or the like in accordance with the alert conditions.If the sensor data matches, exceeds, or otherwise fulfills an alertcondition, then the alert condition may be satisfied. If an alertcondition is satisfied, then process 1100 may flow to block 1110;otherwise, process 1100 may loop to block 1104 to continue to collectadditional sensor data.

At block 1110, an alert may be provided to a user. As described herein,each alert condition may include which type of alert may be provided towhich users upon an alert condition being satisfied. The alert may be anemail, text message, automated phone call, or the like. The alert may beprovided via a user interface, such as user interface 704 of FIG. 7. Insome embodiments, the alert conditions may include escalationinstructions, such that if an alert condition is repeated apredetermined number of times in a given time period, then additionalusers may also be provided an alert or the type of alert may change.

In some embodiments, the alerts may be employed to generate reports orprovide other information to a user. For example, in some embodiments, areport may be generated for each time a pressure value exceeds apredetermined threshold, which may be based on a safety standard. Inanother example, a report of the running time of a machine and/oroperator may be provided to a user (e.g., billing unit, manager, orother business related entity). In this way, a manager or an accountantcan track usage of a machine in comparison to a lease or rentalagreement. It should be recognized that these examples are not limitingor exhaustive and other alerts may be provided based on alert conditionsbeing satisfied.

In some other embodiments, one or more alert conditions may be dependenton one or more other alert conditions being satisfied. For example, if apressure sensor exceed a predetermined threshold (alert conditionsatisfied), then another alert condition may be employed to determine ifthe temperature is above a predetermined threshold. However, embodimentsare not so limited and other alert condition relationships and/or alertsmay be employed.

After block 1110, process 1100 may loop to block 1304 to continue tocollect additional sensor data. Process 1100 may be an adaptive process.As such, the alert conditions may be periodically updated to reflect thecurrent and/or actual usage of the machine.

FIG. 12 illustrates a logical flow diagram generally showing anotherembodiment of a process 1200 for monitoring and managing the usage of amachine that includes a collection of modular components. Process 1200begins, after a start block, at block 1102, where one or more prohibitedconditions for the machine are determined. Prohibited conditions may bedetermined in a similar way to the alert conditions of block 1102 ofprocess 1100 of FIG. 11. For instance, any alert condition occurring inprocess 1100 may be a prohibited condition in other embodiments, such asprocess 1200. Similar to alert conditions of process 1100 of FIG. 11,prohibited conditions may be based on crowd-sourced data.

Furthermore, a prohibited condition may be a prohibited geo-location,time, day, land speed, air speed, water speed of the machine, totalusage time, total cycles on the machine, or the like. A prohibitedcondition may be based on a machine operator, the permissions of amachine operator, a machine load, peak sensor values, a determinedmaintenance requirement, such as a predicted failure date, and the like.A prohibited condition may be based on governmental regulatory schemesthat regulate the operation of the equipment, industry standards,operational and maintenance protocols, and the like.

In at least one embodiment, a prohibited condition may be based on anagreement between an owner of the machine and an operator of themachine. In one exemplary embodiment, the machine operator does not ownthe machine and may be subject to a rental agreement, or some otherterms-of-use agreement. A prohibited condition may be based on the termsof the rental agreement. For instance, one or more prohibited conditionsmay be based on the agreed upon day and/or total time of machine usage,a total number of machine cycles or operations, or limitations on thetime of day, total usage time, dates of use, physical locations of use,and the like. If the operator exceeds any of these limitations, thecorresponding prohibited condition is satisfied.

In at least one embodiment, the sensors may include device that measurea responsivity of the operator. Such sensors may include a devicecapable of determining operator alertness or attentiveness (such as adevice that tracks eye movements), a blood alcohol breathalyzermeasuring device, and the like. Prohibited conditions may be based onlimitations of values provided by such sensors.

At block 1204, the sensor data is collected. In various embodiments,real-time data may be provided from one or more sensors measuringcharacteristics of a machine, which may be collected by a collectioncomputer, such as described herein. Collecting sensor data at block 1204may include similar embodiments to collecting sensor data at block 1104of FIG. 11. At block 1206, the collected sensor data is monitored. Thesensor data may be monitored in real-time, or close to real-time as itis collected in block 1204. The sensor and/or ID Tag data may be stored,logged, or archived in the system database.

In any event, process 1200 may flow to decision block 1208, where adetermination may be made whether a prohibited condition is satisfied.This determination may be based on a comparison of the collected sensordata and the prohibited conditions. For example, the sensor data may bemonitored to determine if a threshold value is exceeded, a rate ofchange is observed, or the like in accordance with the prohibitedconditions. If the sensor data matches, exceeds, or otherwise fulfills aprohibited condition, then the prohibited condition may be satisfied. Ifa prohibited condition is satisfied, then process 1200 may flow to block1210; otherwise, process 1200 may loop to block 1204 to continue tocollect additional sensor data.

At block 1210, the machine usage may be limited based on a prohibitedcondition. For instance, the system may limit the usage of the machineif the operator fails to pass a breathalyze test, pilots the machineinto a restricted area or geo-location, exceeds safe operational speedor weight, exceeds contracted usage such as number hours of operationper day or number of cycles of use, or the like. Limiting the usage ofthe machine may include completely terminating the ability to operatethe machine. In other embodiments, limiting the machine usage mayinclude enabling the operator to operate the machine in a limitedcapacity, until the triggered prohibited condition is cleared or reset.An alert may be provided to instruct the operator as to what steps mustbe taken to bring the machine back into compliance, such that theprohibited condition may be cleared.

At decision block 1212, it is determined whether the prohibitedcondition is resolved. If the condition is not resolved, process 1200flows back to block 1210 to continue limiting the machine usage. If theprohibited condition is resolved, for instance if the operator returnsthe machine usage to an allowable state, process 1200 flows to block1214. In at least one embodiment, the prohibited condition may beresolved remotely, via a user interface, such as user interface 704 ofFIG. 7.

At block 1214, the limits on machine usage are removed and theprohibited condition is cleared. In at least one embodiment, anotification is provided to the user regarding the removal on themachine usage. Process 1200 flows to block 1204, where the operator maycontinue to operate the machine unhindered and sensor data is collected.

Monitoring and Managing the Maintenance of a Machine

FIG. 13 illustrates a logical flow diagram generally showing oneembodiment of a process 1300 for monitoring and managing the maintenanceof a machine that includes a collection of modular components. After astart block, process 1300 proceeds to block 1302 where maintenanceconditions are determined. The maintenance conditions may be machineand/or machine component maintenance conditions. Various embodiments ofdetermining maintenance conditions are discussed in the context of FIG.14. However, briefly the maintenance conditions may be based on at leastone of the previous machine usage, expected machine usage, or componentreliability. As mentioned above, information or data regarding theprevious machine usage, the expected machine usage, and the componentreliability may be accessed via a system database, such as systemdatabase 702 of FIG. 7.

Maintenance conditions may include an approximate date or time remaininguntil a predicted failure or replacement period for a particularcomponent. Maintenance conditions may include scheduled regularmaintenance for the machine, subsystems in the machine, collections ofcomponents, or specific components of the machine. Maintenanceconditions may be assigned a priority based on a criticality of thecomponent or time left before the predictive failure or scheduledmaintenance. When the time remaining to the predicted component failureor scheduled maintenance is less than a predetermined threshold failuretime, the maintenance condition may be triggered. Furthermore, the usermay define one or more maintenance conditions. The maintenanceconditions may be based on crowd-sourced data and/or user networks.

At block 1304, the sensor data is collected. In various embodiments,real-time data may be provided from one or more sensors measuringcharacteristics of a machine, which may be collected by a collectioncomputer, such as described herein. Collecting sensor data at block 1304may be similar to any of the embodiments discussed in the context ofblock 1104 and 1204 of FIGS. 11 and 12 respectively. At block 1306, thecollected sensor data is monitored. The sensor data may be monitored inreal-time, or close to real-time as it is collected in block 1104. Thesensor and/or ID Tag data may be stored, logged, or archived in thesystem database.

In any event, process 1300 flows to decision block 1308, where adetermination may be determined whether a maintenance condition issatisfied. This determination may be based on a comparison of thecollected sensor data and the determined maintenance conditions. Forexample, the sensor data may be monitored to determine if a thresholdvalue is exceeded, a rate of change is observed, or the like inaccordance with the maintenance conditions. If the sensor data matches,exceeds, or otherwise fulfills the maintenance condition, then themaintenance condition may be satisfied. As noted above, in oneembodiment, a maintenance condition may be satisfied if a time toreplace a component is less than a predetermined threshold failure time.If a maintenance condition is satisfied, then process 1300 may flow toblock 1310; otherwise, process 1300 may loop to block 1304 to continueto collect additional sensor data.

At block 1310, process 1300 provides a maintenance notification or alertto a user. Providing a maintenance notification to a user at block 1310may be similar to providing an alert to a user at block 1110 of FIG. 11.The maintenance alert may include information regarding the time toexpected component failure, or the like.

At block 1312, marketplace data is provided to the user. Variousembodiments of providing marketplace data to the user are discussed inthe context of FIG. 15. However, briefly, online marketplace data may beprovided to the user via an e-commerce like user interface, such asmarketplace display 744 of user interface 704 of FIG. 7. The marketplacedata may include an aggregation of e-commerce data regarding options toobtain a replacement and/or replacement component. At least a portion ofthe marketplace data may be crowd-source and/or provided by a usersocial network or a machine type network.

At decision block 1314, it is determined whether the satisfied ortriggered maintenance condition has been resolved. For instance, in someembodiments, the system may give a user, such as a machine operator apredetermined amount of time to resolve the maintenance issue. Resolvingthe maintenance condition may involve replacing a machine componentprior to the expected failure date. If the maintenance condition isadequately and/or timely resolved, process 1300 flows back to block 1304to continue collecting sensor data. Otherwise, process 1300 flows toprocess 1316.

At block 1316, the machine usage is limited. In various embodiments,limiting machine usage at block 1316 may be similar to limiting machineusage at block 1210 of FIG. 12 After the maintenance condition isresolved, limits on the machine usage may be removed, such as accordingto the discussion of block 1214 of FIG. 12. Process 1300 terminatesand/or return to a calling process to perform other actions.

FIG. 14 illustrates a logical flow diagram generally showing oneembodiment of a process 1400 for determining maintenance conditions fora machine that includes a collection of modular components. After astart block, process 1400 proceeds to block 1402, where the previousmachine usage is determined. Determining the machine's previous usagemay be similar to block 1010 of FIG. 10. At block 1404, the expectedmachine usage is determined. Various embodiments for determining theexpected machine usage are discussed in the context of process 1000 ofFIG. 10.

At block 1406 the component reliability is determined for the componentsincluded in the machine. The component reliability is targeted to thecomponent types and the specific instances of components included in themachine. The component reliability may be determined by querying one ormore of the system databases, such as component reliability database 720of FIG. 7. In at least one embodiment, component reliability may bedetermined from crowd-sourced data. In such embodiments, the usercommunity database 728 may be queried. A user's social network or anetwork of users of a similar machine may be employed to crowd-sourcedata that the component reliability is based upon.

At block 1408, one or more maintenance conditions are determined.Maintenance conditions may be based on at least one of the determinedprevious machine usage, expected machine usage, or the componentreliability. In a preferred embodiments, at least a component failuredate and/or rate is predicted. For instance, the component reliabilitymay include a total running time, total number of cycles, or some otherindicated of the lifetime of a component. The previous machine usage mayindicate how much of the component's lifetime has already been consumed.The expected machine usage is used to determined how much more time isleft in the machine's lifetime based on the expected future use of themachine. The predicted failure date or rate is then based on thesedeterminations.

At block 1410, the actual machine usage is determined. Determining theactual machine usage at block 1410 may be similar to determining theactual machine usage as discussed in reference to block 916 of FIG. 9.

At decision block 1412 it is determined if the expected machine usage isto be updated. Determining if the expected usage is to be updated atdecision block 1412 may be similar to the decision performed at decisionblock 918 of FIG. 9. If the expected machine usage is not to be updated,process 1400 proceeds to decision block 1416. Otherwise, process 1400proceeds to block 1414, where the expected machine usage is updatedbased on the actual machine usage. Updating the expected machine usageat block 1414 may be similar to updating the machine usage at block 920of FIG. 9.

At decision block 1416, it is determined if the maintenance conditionsare to be updated. If the maintenance conditions are not to be updated,process 1400 may terminate and/or return to a calling process to performother actions. Otherwise, process 1400 proceeds to block 1418, where themaintenance conditions are updated. In various embodiments, themaintenance conditions are updated based on the updated expected machineusage. In at least one embodiment, the maintenance conditions areupdated based on the actual machine usage. Crowd-generated heuristicsmay be employed to update the maintenance conditions. Process 1400proceeds to block 1410, where the machine is monitored to determine theactual machine use.

FIG. 15 illustrates a logical flow diagram generally showing oneembodiment of a process 1500 for providing marketplace data regardingthe maintenance of a machine that includes a collection of modularcomponents to a user. After a start block, process 1500 proceeds toblock 1502, where the previous usage of the machine is determined. Invarious embodiments, determining the previous usage of the machine atblock 1502 may be similar to determining the previous usage at block1010 of FIG. 10. At block 1504, the expected usage of the machine isdetermined. Various embodiments of determining a previous machine usageare discussed in the context of process 1000 of FIG. 10.

At block 1506, the manufacture's component specification and reliabilitydata is determined. In at least one embodiment, the manufacture'scomponent specification data is determined by querying the componentspecification database 716 of FIG. 7.

At optional block 1508, reliability from the user community may bedetermined based on at least the user community database 728 of FIG. 7.The user's social network may contribute to the user communityreliability data. Also, a community of users of the same or similar typeof machines may contribute to the user community reliability data.

At block 1510, marketplace data regarding replacement components isdetermined. The replacement data is based on a satisfied maintenancecondition, for instance a satisfied maintenance condition of block 1308of FIG. 13. The replacement component data may be directed to componentswith upcoming replacement schedules. The replacement data may beaggregated from part and/or machine suppliers, vendors, and the like.The aggregation may be performed manually or may be curated by one ormore parties. In at least one embodiment, the aggregation may beperformed automatically. The marketplace data may be e-commerce data.

At block 1512, marketplace data regarding alternative replacementcomponents may be determined. The alternative replacement component datamay be based on previous machine usage, expected machine usage,manufacturers' specification and reliability data, and the usercommunity. Alternative replacement components may be suggested by theuser's social network. For instance, a community of users may providesuggestions for alternative components based on the operators actualusage of the machine.

At block 1514, the marketplace, or e-commerce, data is provided to theuser 1514. In one embodiment, the marketplace data is provided to theuser via a user interface, such as user interface 704 of FIG. 7. Atblock 1516, replacement and/or alternative components are provided tothe user based on a user order. The user may be enabled to directlyorder to replacement/alternative parts via the user interface. In atleast one embodiment, the parts may be automatically ordered withoutuser intervention. After block 1516, process 1300 may terminate and/orreturn to a calling process to perform other actions.

FIGS. 16-18, discussed below, describe various embodiments for providinguser community generated analytics and marketplace data for modularsystems, such as any of the systems described herein. FIG. 19illustrates an embodiment of a user interface 1900 for providing amachine user the analytics and marketplace data that are describedthroughout. In some embodiments, at least a portion of the analytics andmarketplace data are provided to a machine user via user interface 704of system 700 of FIG. 7. In at least one embodiment user interface 1900is included in system 700 of FIG. 7. Portions of user interface 1900 andinterface 704 are discussed in the context of processes 800, 900, 1000,1100, 1200, 1300, 1400, 1500, 1600, 1700, 1720, or 1800 of FIG. 8, 9,10, 11, 12, 13, 14, 15, 16, 17A, 17B, or 18 respectively. In at leastsome embodiments, user interface 1900 is included in system 700 of FIG.7. As such, any user interactions provided via user interface 704 ofFIG. 7, such as providing machine data, analytics, marketplace data, andthe like, may be provided to a user via user interface 1900. Likewise,any information provided to a user via user interface 1900 may beprovided to a user via user interface 704.

User interface (UI) 1900 may be used by a machine user, such as machineuser User_A, or any other member of the user community. As shown in FIG.19, UI 1900 is providing User_A various information, including communitygenerated analytics and marketplace data. Furthermore, UI 1900 isenabling User_A to provide data and information, including analytics andany marketplace data generate by and/or specific to User_A or anymachines associated with User_A, to the user community. Furthermore, UI1900 enables User_A to form a social network and communicate informationto peers within User_A's social network, as well as other users of theuser community. In various embodiments, UI 1900 is provided to User_Avia a display device of any computer, including but not limited toclient computer 102-105 of FIG. 1, client computer 200 of FIG. 2, servercomputer 400 of FIG. 4, and the like. It should be understood that inthe various embodiments, the information provided to a user of any userinterface discussed herein, including but not limited to UI 1900 and UI704 of FIG. 7, may be customized based on a customization of one or moretemplates, such as but not limited to analytic templates and marketplacedata templates. For instance, the status of the user, the user's socialnetwork, the status of a particular machine, the components,configurations, and maintenance of a particular machine, and the likemay each be customized based on templates.

Members of the user community may have one or more member statuses, suchas machine user, component vendor, machine vendor, regulatory body,municipality, and the like. A UI portion 1902 of UI 1900 illustratesthat User_A has a status of a machine user, as well as status of acomponent vendor. Accordingly, User_A uses machines as well as sellscomponents for machines in an electronic marketplace that contributes tothe marketplace data shown in UI portion 1914.

UI portion 1916 may display one or more components included inMachine_A, such as P1, P2, P3, and the like. The components may beautomatically or manually identified, as discussed in the variousembodiments herein. For each component or part, UI portion 1916 mayprovide links or other access to configuration files, maintenance files,sensor log files, or other analytics regarding Machine_A. In at leastone embodiment, UI portion 1916 also provides at least an expected dateor deadline regarded expected maintenance, determined in a maintenancepredictive analysis. For instance, system 700 of FIG. 7 may predict thatcomponent P1 will be required to be replaced and/or maintained by Jun.17, 2018. At least a portion of the information shown in UI portion 1916may be based on information provided by system database 702 of FIG. 7,such as machine and component usage database 718, maintenance database724, component reliability database 720.

Furthermore, UI portion 1902 may show various data regarding the userprofile of User_A, including, but not limited to, machines associatedwith User_A. As shown in UI portion 1902, at least Machine_A, Machine_B,and Machine_C are associated with User_A.

FIG. 16 illustrates a logical flow diagram generally showing oneembodiment of a process for providing user community generated analyticsand marketplace data for modular systems that are consistent with thevarious embodiments described herein. Process 1600 may begin, after atstart block, at block 1602, where a machine is determined. Variousembodiments of determining a machine are discussed throughout, includingat least in the context of FIGS. 8, 9, and 10. However briefly, at block1602, a machine type may be determined based on interrogating orreceiving data from a plurality of ID Tags associated with componentsincluded in the machine. Furthermore, the machine may be uniquelyidentified as a specific instance of the machine type. The specificallyidentified machine may be uniquely defined by a serial number or thelike based on the self-identified components types and/or specificinstances of the self-identified components. For instance, the machinemay be uniquely identified.

In at least one embodiment, the machine includes a dedicated ID_Tag thatincludes identification data for at least the machine type or the uniqueinstance of the machine. In such embodiments, the identification of theincluded components and/or component types may not be required. Thedetermination at block 1602 may be an automatic determination. A machineuser may be prompted to confirm the determination of the machine and/orprovide additional information. In at least some embodiments, thedetermination may be based on at least components that were manuallyentered by the machine user. In various embodiments, once a machine orat least a machine type has been determined, the machine may beassociated with a user. For instance, UI portion 1902 of UI 1900 showsthat User_A is a user of, or at least associated with, multiplemachines, including Machine_A, Machine_B, and Machine_C.

In some embodiments, as discussed throughout, determining a machine mayinclude determining a machine usage. Determining a machine usage mayinclude determining an expected machine usage, a previous machine usage,an actual machine usage, and the like. For instance, determining amachine usage is discussed, at least in conjunction with process 900 ofFIG. 9, process 1000 of FIG. 10, process 14 of FIG. 14, and process 1500of FIG. 15. Furthermore, determining a machine may include determining ageographical location and/or an environment of the machine, as discussedthroughout, including at least process 1000. Essentially, at block 1602,any determinations as discussed herein may be determined, including butnot limited to any block of processes 800, 900, and 1000 of FIGS. 8, 9,and 10.

At decision block 1604, the machine user may decide whether to opt-intoa user community, wherein the user community includes but is nototherwise limited to any of the exemplary embodiments of usercommunities discussed herein. If the machine user decides to opt-intothe user community, process 1600 flows to block 1606. Otherwise, process1600 may terminate and/or return to a calling process to perform otheractions. For instance, if the machine user does not decide to opt-intothe user community, any other process described herein may be performed,such as, but not limited to processes 800, 900, 1000, 1100, 1200, 1300,1400, or 1500 of FIGS. 8, 9, 10, 11, 12, 13, 14, and 15, respectively.

In at least one embodiment, the user must opt-out of the user community.In such an embodiment, unless the machine user opts-out of the usercommunity, process 1600 will flow to block 1606. If the user does decideto opt-out of the user community, process 1600 may terminate.

In various embodiments, a machine user that has opted-into the usercommunity (or alternatively, has not opted-out) may form a socialnetwork that includes one or more other individuals or members withinthe user community. The other users within the machine user's socialnetwork may be peers. UI portion 1904 of UI 1900 of FIG. 19 shows thatUser_A has opted into the user community and has formed a socialnetwork. The social network of a user may include a social graph. Asshown by UI portion 1904, the peers within User_A's social networkinclude User_L, User_M, User_N, User_X, and the like.

At least a portion of the peers within a social network may beassociated with one or more machines. For instance, UI portion 1904illustrates that User_L, User_N, and User_X are each associated withMachin_A, of which User_A is also associated with. These users may beassociated with Machine_A, because these users are users of anequivalent machine to the machine type of Machine_A, or at least asimilar machine to that of Machine_A. In some embodiments, at least onethese users associated with Machine_A may be a vendor or supplier of anequivalent machine or a machine that is similar to Machine_A, or may bea component vendor for component types that may be included in, or usedin conjunction with, Machine_A.

At block 1606, one or more peers are recommended to the user to includein the user's social network. The recommended peers may be based on adetermined machine, such as the machine determined at block 1602, orduring any other process described herein. In various embodiments, therecommended peers may be based on the determined machine type. In someembodiments, the recommendation of a peer may be based on an associationbetween the recommended peer and the machine, machine type, or the like.In at least one embodiment, the recommended peers are based on theuniquely identified machine.

UI portion 1904 of UI 1900 shows that User_D has been recommended as apeer to include in User_A's social network, based on User_A'sassociation with Machine_A. User_D is not currently a member of User_A'ssocial network, but User_D may also be associated with a machineequivalent or at least similar to Machine_A. For instance, User_D mayalso be a user of a machine that is at least similar to Machine_A, or avendor of Machine_A. Likewise, User_F has been recommended as a peer toUser_A, based on both User_A's association and User_F's association withMachine_C. User_A may add one or more of the recommended peers, or anyother member of the user community, to User_A's social network, via arequest that may be initiated by contacting the recommended peer, asenabled by UI portion 1906. User_A may communicate messages, data, andthe like via contacting a peer, a recommended peer, or another member ofthe user community via UI portion 1906.

In various embodiments, recommending peers is based on at least ageographic (geo-) location of the machine or the machine user. Forinstance, peers may be recommended based on a proximity between the userand the recommended peers. Likewise, peers may be recommended based onan environment, or at least an environmental parameter, of a machineassociated with the user and/or one or more machines of the recommendedpeer. For instance, a peer may be recommended to User_A because User_Auses one or more machines in a desert environment, and the recommendedpeer also has used machines in a desert environment.

At block 1608, various analytics are provided to the machine user.Various embodiments of providing the machine user with analytics arediscussed in conjunction with at least process 1700 of FIG. 17A. Howeverbriefly, at least a portion of the analytics may be for the machine ormachine type determined at block 1602. In some embodiments, theanalytics are for a machine selected in a UI, such as UI 704 of FIG. 7or UI 1900 of FIG. 19. The analytics may include, but are not limited toanalytics related to machine component reliability, machine maintenanceconditions, machine prohibited conditions, machine usages, machine alertconditions, and the like. The analytics may include virtually anyinformation about a machine associated with the user, or other machinesassociated with members of the user community.

As discussed throughout, analytics may include information or datastored in any databases described herein, including but not limited tosystem databases 702 of system 700 of FIG. 7. The analytics may be basedon machine data generated by the user's machine. For instance, theanalytics may be based on machine data generated by the ID Tags andsensors included in the user's associated machines. The analytics mayalso be based on machine data generated by equivalent or similarmachines associated with other members of the user community. Forinstance, the analytics may be based on data generated by the ID Tagsand/or sensors included in the other machines associated with the othermembers of the user community. In exemplary embodiments, the analyticsmay be based on the component reliability, maintenance conditions,prohibited conditions, machine and/or component logs, configurations,and the like, as determined by the various embodiments described hereinfor machines associated with members of the user community.

Accordingly, machine data may include any data generated by any machineassociated with one or more members of the user community. In someembodiments, the analytics may be based on statistical distributions ofthe machine data. In at least one embodiment, at least a portion of theanalytics are based on one or more moments of the statisticaldistributions of the machine data, such as the mean, the standarddeviation, and the like. For instance, a component reliability analyticfor a particular component included in the user's machine may be similarto, or even equivalent to, the mean time to failure of the component, asused by other members of the community in a similar application to thatof the user that is being provided the analytic. The analytics may bebased on anecdotal data provided by one or more members of thecommunity, such as component and/or machine reviewer and comments, andthe like.

At least a portion of the analytics may be generated based on machinedata provided by peers within the user's social network. As discussedthroughout, at least a portion of the analytics may be provided to theuser via a user interface, such as UI 1900 of FIG. 19 or UI 704 of FIG.7. UI portion 1912 of UI 1900 shows an exemplary embodiment of providingUser_A with user community generated analytics. The analytics providedin UI portion 1912 may be based on a customization of an analyticstemplate. As shown in UI portion 1912, the provided analytics may besubdivided into analytics based on machine data specific to peers withinUser_A's social network and analytics based on machine data provided bythe user community as a whole. For instance, the component reliability,the maintenance condition, the prohibited condition, and other suchanalytics generated based on the statistical distributions of machinedata provided by the User_A's peers may be shown in one section of UIportion 1912, while the corresponding analytics generated by the machinedata of a larger portion of the user community may be shown in anothersection of UI portion 1912.

At block 1610, marketplace data is provided to the machine user. Variousembodiments of providing the machine user with marketplace data arediscussed in conjunction with at least process 1800 of FIG. 18. Howeverbriefly, at least a portion of the marketplace data may be for themachine or machine type determined at block 1602. The marketplace datamay include information relating to the maintenance of the machine,replacement components or alternative components for the machine, andthe like for various machines. Marketplace data may include anaggregation of electronic (e)-commerce data. Marketplace data may beprovided (automatically or manually) may be based on data aggregatedfrom various sources, including vendors, suppliers, buyers, sellers,online auctioneers, members of the user community, and the like.

At least a portion of the marketplace data may be based on machine dataprovided by the user community. As such, the marketplace data may begenerated by the user community. At least a portion of the usercommunity generated marketplace data may be generated by peers withinthe machine user's social network. The marketplace data may be providedto the machine user via a user interface, such as UI 1900 of FIG. 19. UIportion 1914 of UI 1900 shows an exemplary embodiment of providingUser_A with marketplace data. The marketplace data provided in UIportion 1914 may be based on a customization of a marketplace datatemplate. Process 1600 may terminate and/or return to a calling processto perform other actions.

FIG. 17A illustrates a logical flow diagram generally showing oneembodiment of a process for providing user community generated analyticsfor modular systems that are consistent with the various embodimentsdescribed herein. Process 1700 begins, after a start block, at block1702 where an analytics template is customized. Customizing theanalytics template may enable a customization of which analytics aredetermined and how the determined analytics are provided to a user, suchas a user of a user interface.

The user may customize the analytics template to indicate whichanalytics are provided and a structure for the provided analytics, aswell as which members of the user community contribute machine data, aswell as reviews, comments, and the like to determine the analytics. Insome embodiments, customizing the analytics template may includeindicating which analytics are to be provided. Customizing the analyticstemplate may include indicating which members of the user community mayprovide the machine data to determine the various analytics. Forinstance, a portion of the analytics may be based on machine dataprovided by only peers of the user. Other analytics may be based onmachine data provided by a larger subset of members of the usercommunity.

UI portion 1912 of UI 1900 of FIG. 19, as well various portions of UI704 of FIG. 7, shows various analytics provided to machine user.Customizing the analytics template may configure which analytics aredetermined and how the analytics are shown and organized in UI portion1912, as well as UI 704.

At block 1704, various analytics are determined based on the customizedanalytics template. Various embodiments of determining analytics arediscussed in at least conjunction with process 1720 of FIG. 17B.However, briefly, at least a portion of the analytics may be generatedbased on machine data, user reviews, user comments, and the likeprovided by members of the user community. For instance, members of theuser community may provide ID Tag and sensor data for components,reliability data for components, prohibited, or maintenance conditionsof the machines that they have used and the like, as determined by thevarious embodiments discussed herein.

At least a portion of the user community generated analytics may begenerated based on machine data, user reviews, user comments, and thelike provided by the peers within the user's social network. The variousanalytics may be associated with a machine associated with the user. Forinstance, UI portion 1912 provides user community and peer generatedanalytics associated with Machine_A. Analytics associated with othermachines associated with the user may be presented by selecting anothermachine within UI 1900.

As discussed throughout, determining analytics may include determining amachine user and/or a user community. Various embodiments fordetermining a machine user and/or a user community are discussed in atleast the context of process 1000 of FIG. 10. Analytics associated witha machine may include virtually any information or data (includingID_Tag and sensor data) associated with the machine. For instance, theuser community generated analytics may include, but are not limited tocomponent reliability analytics, maintenance condition analytics,prohibited condition analytics, machine usage (previous, expected,actual, and the like) analytics, alert condition analytics, and thelike. The analytics may include log files for other machines that areused by users in the user community. At least a portion of the anticsmay be based on a machine user associated with the machine.

At least a portion of the determined analytics may be associated with aparticular machine. For instance, UI portion 1908 of UI 1900 showsanalytics that are particularized to Machine_A. Some of these analyticsmay be directed to a status of Machine_A. For instance, analytics mayinclude the type of machine, a unique machine ID, at least anapproximate geo-location of the machine, an approximate elevation of themachine, an environment of the machine, usage type, machine utilization,duty cycle, and the like. Analytics may include log files for theparticular machine.

As noted throughout, the analytics for the machine may include componentreliability analytics for at least a portion of the components includedin a particular machine associated with the user. Component reliabilityanalytics may include determined component reliability. In variousembodiments, the component reliability analytics may include componentreliability, such as that determined in conjunction with at least block1406 of process 1400 of FIG. 14, or any other embodiments describedherein. Analytics for the machine may include maintenance conditions asdetermined by any of the various embodiments described herein. Analyticsmay also include prohibited conditions as determined by any of thevarious embodiments described herein. The analytics may include logfiles for machines used by members of the user community.

At block 1706, at least a portion of the determined analytics are usedto populate the customized analytics template. The customization of theanalytics template at block 1702 may determine which analytics are usedto populate the analytics template. At block 1708, the populatedanalytics template is provided to a user. For instance, the populatedanalytics template may be provided to a user via a user interface, suchas UI 1900.

At decision block 1710, it is determined whether the user will providemachine data, user reviews, user comments, and the like to contribute tothe user community generated analytics. For instance, due to privacyconcerns, a user may wish to keep at least a portion of the machine datagenerated by one or more of the machines associated with them private.In such embodiments, process 1700 may terminate and/or return to acalling process to perform other actions. Otherwise, process 1700 flowsto block 1712.

At block 1712, the user provides at least a portion of the machine datacorresponding to one or more of the user's associated machines. Forinstance, ID Tag and/or sensor generated data may be provided toplatform 140 of FIG. 1. Such machine data may be used to generate atleast a portion of the analytics discussed herein. The user mayadditionally provide log files for one or more of their associatedmachines, any of the data shown in any user interface discussed herein,such as UI portion 1908 of UI 1900, users reviews, comments, and thelike. For instance, the user may provide configuration log files, usagelog files, maintenance log files, and the like. The user may setpermissions on the log files, regarding who in the user community mayaccess the various log files. For instance, the user may set permissionssuch that the log files may only be accessed by peers. In at least oneembodiment, the user may set a permission that indicates that the logfiles must be anonymized prior to being shared with other members of theuser community. In at least one embodiment, the user may set apermission that indicates that the machine data included in the logfiles may be used to contribute to the statistical distributions of theuser community to generate analytics, but the log files may not beotherwise accessible to members of the user community. In variousembodiments, the machine data used to generate the various analytics maybe provided by the members in the user community via such log files. Inat least one embodiment, the machine data that is provided at block 1712is based on the customized analytics template. Process 1700 mayterminate and/or return to a calling process to perform other actions.

FIG. 17B illustrates a logical flow diagram generally showing oneembodiment of a process for determining user community generatedanalytics for modular systems that are consistent with the variousembodiments described herein. After a start block, process 1720 beginsat block 1722, where machine configurations are determined based on theuser community. In at least one embodiment, the machine configurationsare determined based on the machine configurations of machinesassociated with members of the user community and/or the machineconfigurations of machines associated with the peers of the user. Themachine configurations may be based on a machine selected by the user tobe provided the analytics. In at least one embodiment, the machineconfigurations are determined for one or more machines associated withone or more members of the user community. The one or more members ofthe user community may include one or more peers included in the user'ssocial network. Various embodiments for determining machineconfigurations are discussed throughout, including at least inconjunction with processes 800 and 900 of FIGS. 8 and 9. Theconfigurations may be provided via a configuration log file.

At block 1724, the component reliability for one or more components isdetermined based on the user community. In at least one embodiment, oneor more component reliabilities are determined based on the componentreliabilities for component types included in machines associated withmembers of the user community and/or the component reliabilities ofcomponent types included in machines associated with the peers of theuser. The one or more components may be a component type included in amachine associated with the user that the analytics are being providedto. For instance, in various embodiments, the one or more components mayinclude component types that are included in Machine_A, of UI 1900 ofFIG. 19, because Machine_A is associated with User_A of UI 1900.

Various embodiments for determining the component reliability ofcomponents are discussed at least in conjunction with process 1400 ofFIG. 14 or any other process discussed herein. The component reliabilitymay be determined based on various component reliability distributionsgenerated from the component reliabilities of component types includedin machines associated with members of the user community and/or peersincluded in the user's social network. The one or more componentreliabilities may be based on a component reliability database, such ascomponent reliability database 720 of FIG. 7.

At block 1726, the maintenance conditions for one or more machines aredetermined based on the user community. In at least one embodiment, oneor more maintenance conditions are determined based on the maintenanceconditions for machines associated with members of the user communityand/or the maintenance conditions of machines associated with the peersof the user to be provided analytics. The one or more maintenanceconditions may be based on the one or more component reliabilitiesdetermined at block 1724 or within any other process described herein.The one or more maintenance conditions may be a maintenance conditionsfor a machine associated with the user that the analytics are beingprovided to. For instance, in various embodiments, the determined one ormore maintenance conditions may be maintenance conditions for Machine_Aassociated with User_A of UI 1900.

Various embodiments for determining the maintenance conditions ofmachines are discussed at least in conjunction with process 1300 andprocess 1400 of FIGS. 13-14. The maintenance conditions may be based onvarious maintenance condition distributions generated from maintenanceconditions of machines associated with members of the user communityand/or peers included in the user's social network. The one or moremaintenance conditions may be based on a maintenance database, such asmaintenance database 722 of FIG. 7. The one or more maintenanceconditions may be based on a maintenance file or maintenance log file ofone or more machines or one or more members of the user community.

At block 1728, the prohibited conditions for one or more machines aredetermined based on the user community. In at least one embodiment, oneor more prohibited conditions are determined based on the prohibitedconditions for machines associated with members of the user communityand/or the prohibited conditions for machines associated with the peersof the user to be provided analytics. The one or more prohibitedconditions may be based on the one or more component reliabilitiesdetermined at block 1724 or within any other process described herein.The one or more prohibited conditions may be a prohibited conditions fora machine associated with the user that the analytics are being providedto. For instance, in various embodiments, the determined one or moreprohibited conditions may be prohibited conditions for Machine_Aassociated with User_A of UI 1900.

Various embodiments for determining the prohibited conditions ofmachines are discussed at least in conjunction with process 1200 of FIG.12. The prohibited conditions may be based on various prohibitedcondition distributions generated from prohibited conditions of machinesassociated with members of the user community and/or peers included inthe user's social network. The one or more prohibited conditions may bebased on a data included in a database, such as any of the databasesincluded in system database 702 of FIG. 7. The one or more prohibitedconditions may be based on data included in a file or log file of one ormore machines or one or more members of the user community.

At block 1730, the alert conditions for one or more machines aredetermined based on the user community. In at least one embodiment, oneor more alert conditions are determined based on the alert conditionsfor machines associated with members of the user community and/or thealert conditions for machines associated with the peers of the user tobe provided analytics. The one or more alert conditions may be based onthe one or more component reliabilities determined at block 1724 orwithin any other process described herein. The one or more alertconditions may be alert conditions for a machine associated with theuser that the analytics are being provided to. For instance, in variousembodiments, the determined one or more alert conditions may beprohibited conditions for Machine_A associated with User_A of UI 1900.

Various embodiments for determining the alert conditions of machines arediscussed at least in conjunction with process 1100 of FIG. 11. Thealert conditions may be based on various alert condition distributionsgenerated from alert conditions of machines associated with members ofthe user community and/or peers included in the user's social network.The one or more alert conditions may be based on a data included in adatabase, such as any of the databases included in system database 702of FIG. 7. The one or more alert conditions may be based on dataincluded in a file or a log file of one or more machines or one or moremembers of the user community.

At block 1732, the machine usage for one or more machines are determinedbased on the user community. In at least one embodiment, machine usageis determined for one or more machines associated with members of theuser community and/or one or more machines associated with the peers ofthe user to be provided analytics. The determined machine usage may beexpected machine usage, actual machine usage, or the like. The machineusage may be for a machine associated with the user that the analyticsare being provided to. For instance, in various embodiments, thedetermined machine usage may be for Machine_A associated with User_A ofUI 1900. The determined machine usage may include usage type,utilization, duty cycle, and the like. Machine usage may include ageo-location, elevation, and/or one or more environmental parameters ofthe machine or machine's geo-locaton.

Various embodiments for determining the alert conditions of machines arediscussed at least in conjunction with process 800, process 900, andprocess 1000 of FIGS. 8, 9, and 10. The machine usage may be based onvarious machine usage distributions generated from machine usages formachines associated with members of the user community and/or peersincluded in the user's social network. The one or more determinedmachine usages may be based on a data included in a database, such asany of the databases included in system database 702 of FIG. 7. The oneor more machine usages may be based on data included in a file or a logfile of one or more machines or one or more members of the usercommunity. Such log files may include machine usage log files.

At block 1734, one or more analytics are determined. The determinedanalytics may be based on any of the configurations, componentreliabilities, maintenance conditions, prohibited conditions, alertconditions, machine usage, and the like. In at least one embodiment, theanalytics may be based on reviews and/or comments provided by members ofthe user community, including peers of the user to be provided thedetermined analytics. In some embodiments, the determined analytics aredetermined by an analytics template. The analytics template may be acustomized template. Process 1700 may terminate and/or return to acalling process to perform other actions.

FIG. 18 illustrates a logical flow diagram generally showing oneembodiment of a process for providing user community generatedmarketplace data for modular systems that are consistent with thevarious embodiments described herein. Process 1800 begins, after a startblock, at block 1802 where a marketplace template is customized.Customizing the marketplace template may enable a customization of whichmarketplace data is determined and how the determined marketplace datais provided to a user, such as a user of a user interface.

The user may customize the marketplace template to indicate whichmarketplace data is provided and a structure for the providedmarketplace data, as well as which members of the user communitycontribute data, as well as reviews, comments, and the like to determinethe marketplace data. In some embodiments, customizing the marketplacedata template may include indicating which marketplace data is to beprovided. Customizing the marketplace data template may includeindicating which members of the user community may provide the data. Forinstance, a portion of the marketplace data may be based on anaggregation of marketplace data provided by only peers of the user.Other embodiments of marketplace data may be based on an aggregation ofmarketplace data provided by a larger subset of members of the usercommunity.

UI portion 1914 of UI 1900 of FIG. 19, as well various portions of UI704 of FIG. 7, such as marketplace display 744, shows various analyticsprovided to machine user. Customizing the marketplace template mayconfigure which marketplace data is determined and how the marketplacedata is shown and organized in UI portion 1914, as well as UI 704.

At block 1804, various marketplace data is determined based on thecustomized customized marketplace template. Various embodiments ofdetermining marketplace data are discussed in at least conjunction withprocess 1500 of FIG. 15. However, briefly, at least a portion of themarketplace data may be generated based on machine data, user reviews,user comments, and the like provided by members of the user community.The marketplace data may be an aggregation of marketplace data, machinedata, and the like provided by various machine and component vendors.

At least a portion of the user community generated marketplace data maybe generated based on machine data, user reviews, user comments, and thelike provided by the peers within the user's social network. Forinstance, the user's peers or other members of the user community mayprovide reviews and/or comments of the services provided by variousmachine and/or component vendors. The marketplace data may be associatedwith a machine associated with the user. For instance, UI portion 1914of FIG. 19 and marketplace display 744 of FIG. 7, provide user communityand peer generated marketplace data associated with Machine_A.Marketplace data associated with other machines associated with the usermay be presented by selecting another machine within UI 1900.

As discussed throughout, determining marketplace data may includedetermining a machine user and/or a user community. Various embodimentsfor determining a machine user and/or a user community are discussed inat least the context of process 1000 of FIG. 10. Marketplace dataassociated with a machine may include virtually any information or datapertaining to online or e-commerce regarding the machine and/or machinecomponents. For instance, the user community generated marketplace datamay include, but are not limited to expected maintenance dates for themachine and/or machine components, which vendors may provide componentsthe fastest, the most cost effective, and the like, as well as lists ofpreferred vendors. The marketplace data may include expected dates atwhich the various vendors or suppliers may provide replacement and/oralternative components. The marketplace data may include alternativecomponent types for components that have an associated upcoming expectedmaintenance date. The marketplace data may include user communitygenerated reviews and comments of components, suppliers, vendors, andthe like. Such reviews and comments may be provided and/or filtered bythe user's peers and the like.

At least a portion of the determined marketplace data may be associatedwith a particular machine. For instance, UI portion 1914 of UI 1900, andmarketplace display 744 of UI 704, shows marketplace data that isparticularized to Machine_A. Some of this marketplace data may bedirected to a status of Machine_A. For instance, recommended vendors maybased on the type of machine, a unique machine ID, at least anapproximate geo-location of the machine, an approximate elevation of themachine, an environment of the machine, usage type, machine utilization,duty cycle, and the like.

At block 1806, at least a portion of the determined marketplace data isused to populate the customized marketplace template. The customizationof the marketplace template at block 1802 may determine whichmarketplace data is used to populate the marketplace template. At block1808, the populated analytics template is provided to a user. Forinstance, the populated marketplace template may be provided to a uservia a user interface, such as UI 1900 of FIG. 19 or UI 704 of FIG. 7.

At decision block 1810, it is determined whether the user will providemarketplace data to contribute to the user community generatedmarketplace data. For instance, due to privacy concerns, a user may notwish to provide reviews or comments regarding components, vendors,suppliers, and the like. In such embodiments, process 1800 may terminateand/or return to a calling process to perform other actions. Otherwise,process 1800 flows to block 1812.

At block 1812, the user provides marketplace data corresponding to oneor more of the user's associated machines. As shown in UI portion 1902of UI 1900, in addition to being a machine user, User_A is also acomponent vendor. As such, User_A may provide marketplace data to theuser community. Such user provided marketplace data may be used togenerate at least a portion of the user community generated marketplacedata discussed herein. The user may provide marketplace data, includingbut not limited to cost, availability, expected delivery dates, and thelike for various machines, components, and the like. At least a portionof the marketplace data may be based on machine data. The user mayprovide reviews and/or comments regarding other vendors, suppliers, andthe like. The user may also provide reviews and/or comments regardingother machines, machine components, and the like. The user may setpermissions on for the marketplace data, regarding who in the usercommunity may access the provided marketplace data. For instance, theuser may set permissions such that at least portions of the marketplacedata may only be accessed by peers. In at least one embodiment, the usermay set a permission that indicates that at least portions of themarketplace data must be anonymized prior to being shared with othermembers of the user community. For instance, their reviews must beanonymized. In at least one embodiment, the marketplace data that isprovided at block 1812 is based on the customized marketplace template.Process 1800 may terminate and/or return to a calling process to performother actions.

The above specification, examples, and data provide a completedescription of the manufacture and use of the composition of theinvention. Since many embodiments of the invention can be made withoutdeparting from the spirit and scope of the invention, the inventionresides in the claims hereinafter appended.

What is claimed as new and desired to be protected by Letters Patent ofthe United States is:
 1. A method for managing a machine, comprising:communicating, to a collection computer, component identification dataseparately stored in each of a plurality of component identification(ID) Tags that correspond to one or more components for the machine,wherein the component identification data includes a component type;automatically determining a machine type of the machine based on acomparison of the one or more component types and one or more previouslyprovided combinations of component types that correspond to one or morepreviously determined machine types; recommending one or more candidatepeers to include in a social network of a user based on one or more ofthe component types or the machine type, wherein the one or morecandidate peers are included in a user community; providing an analyticstemplate to the user, wherein the analytics template is populated withanalytics for the machine type based on machine data provided by theuser community; and providing a marketplace template to the user,wherein the marketplace template is populated with marketplace data forthe machine type based on the machine data provided by the usercommunity.